-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 14 pull requests #33354
Merged
Merged
Rollup of 14 pull requests #33354
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* implement Display on Token instead of custom tok_str() fn * use expression returns * remove redundant parens in asserts * remove "/* bad */" comments that appear to be related to early changes in memory management * and a few individual idiomatic changes
Caught as catchall patterns are: * unconditional name bindings * references to them * tuple bindings with catchall elements Fixes rust-lang#31221.
* It is not clear what a "base function" is. * The suggestion just adds parens, so suggests calling without args. The second point could be fixed with e.g. `(...)` instead of `()`, but the preceding "note: X is a function, perhaps you wish to call it" should already be clear enough. Fixes: rust-lang#31341
In situations where the value of the last expression must be inferred, rustc will not emit the "you might need to remove the semicolon" warning, so at least note this in the extended description. Fixes: rust-lang#30497
This is curiously missing from both the short message and this long diagnostic. Refs rust-lang#31573 (not sure if it should be considered "fixed" as the short message still only refers to extern crates).
Current code leads to messages like "... use a \xHH escape: \u{e4}" which is confusing. The printed span already points to the offending character, which should be enough to identify the non-ASCII problem. Fixes: rust-lang#29088
Current description of `std::mem::size_of` is ambiguous, and the `std::intrinsics::size_of` description incorrectly defines size as the number of bytes necessary to exactly overwrite a value, not including the padding between elements necessary in a vector or structure.
Currently the link refers to it's own section of the documentation rather than the list of functions generated by rustdoc.
MultiSpan model is now: - set of primary spans - set of span+label pairs Primary spans render with `^^^`, secondary spans with `---`. Labels are placed next to the `^^^` or `---` marker as appropriate.
Each Span now carries a `is_primary` boolean along with an optional label. If there are multiple labels for a span, it will appear multiple times.
This uses the new `span_label` APIs
Major changes: - Remove old snippet rendering code and use the new stuff. - Introduce `span_label` method to add a label - Remove EndSpan mode and replace with a fn to get the last character of a span. - Stop using `Option<MultiSpan>` and just use an empty `MultiSpan` - and probably a bunch of other stuff :)
This API pulls the "expected type foo, found type bar" out after the main snippet. There are some other places where it makes sense, but this is a start.
Track the span corresponding to the `|...|` part of the closure.
The extra filename and line was mainly there to keep the indentation relative to the main snippet; now that this doesn't include filename/line-number as a prefix, it is distracted.
The Yellow text is very hard to read with a white background.
It's primary purpose was to check that json worked at all, but compiletest does that now.
It is way easier to copy-and-paste strings from the output than to figure out how to reproduce them from first principles.
There is now a CoreEmitter that everything desugars to, but without losing any information. Also remove RenderSpan::FileLine. This lets the rustc_driver tests build.
@bors r+ force |
📌 Commit a176a46 has been approved by |
⌛ Testing commit a176a46 with merge e44aefa... |
💔 Test failed - auto-linux-64-opt-rustbuild |
@bors r+ force |
📌 Commit cdbcbd0 has been approved by |
bors
added a commit
that referenced
this pull request
May 2, 2016
💔 Test failed - auto-mac-64-opt-rustbuild |
Overhaul borrowck error messages and compiler error formatting generally This is a major overhaul of how the compiler reports errors. The primary goal is to be able to give many spans within the same overall context, such as this: ``` ./borrow-errors.rs:73:17: 73:20: error: cannot borrow `*vec` as immutable because previous closure requires unique access [E0501] 70 let append = |e| { ~~~ closure construction occurs here 71 vec.push(e) ~~~ previous borrow occurs due to use of `vec` in closure 72 }; 73 let data = &vec[3]; ~~~ borrow occurs here 74 } ~ borrow from closure ends here ``` However, in the process we made a number of other changes: - Removed the repetitive filenames from snippets and just give the line number. - Color the line numbers blue so they "fade away" - Remove the file name and line number from the error code suggestions since they don't seem to fit anymore. (This should probably happen in more places, like existing notes.) - Newlines in between errors to help group them better. This PR is not quite ready to land, but we thought it made sense to stop here and get some feedback from people at large. It'd be great if people can check out the branch and play with it. We'd be especially interested in hearing about cases that don't look good with the new formatting (I suspect they exist). Here is a checklist of some pending work items for this PR. Some of them may be best left for follow-up PRs: - [x] Accommodate multiple files in a `MultiSpan` (this should be easy) - In this case, we want to print filenames though. - [x] Remove duplicate E0500 code. - [x] Make the header message bold, rather than current hack that makes all errors/warnings bold - [x] Update warning text color (yellow is hard to read w/ a white background) Moved numerous follow-ups to: rust-lang#33240 Joint work with @jonathandturner. Fixes rust-lang#3533
Make libsyntax::print::pp more idiomatic Minor cleanup, and using VecDeque as a ring buffer instead of a vector.
diagnostics for E0432: imports are relative to crate root This is curiously missing from both the short message and this long diagnostic. Refs rust-lang#31573 (not sure if it should be considered "fixed" as the short message still only refers to extern crates).
match check: note "catchall" patterns in unreachable error Caught as catchall patterns are: * unconditional name bindings * references to them * tuple bindings with catchall elements Fixes rust-lang#31221.
…Gomez E0269: add suggestion to check for trailing semicolons In situations where the value of the last expression must be inferred, rustc will not emit the "you might need to remove the semicolon" warning, so at least note this in the extended description. Fixes: rust-lang#30497
typeck: remove confusing suggestion for calling a fn type * It is not clear what a "base function" is. * The suggestion just adds parens, so suggests calling without args. The second point could be fixed with e.g. `(...)` instead of `()`, but the preceding "note: X is a function, perhaps you wish to call it" should already be clear enough. Fixes: rust-lang#31341
…ichaelwoerister rustc: Handle concurrent `create_dir` requests The compiler created a directory as part of `-Z incremental` but that may be hierarchically used concurrently so we need to protect ourselves against that.
lexer: do not display char confusingly in error message Current code leads to messages like `... use a \xHH escape: \u{e4}` which is confusing. The printed span already points to the offending character, which should be enough to identify the non-ASCII problem. Fixes: rust-lang#29088
docs: Changed docs for `size_of` to describe size as a stride offset Current documentation for `std::mem::size_of` is ambiguous, and the documentation for `std::intrinsics::size_of` incorrectly defines size. This fix re-defines size as the offset in bytes between successive instances of a type, as described in LLVM's [getTypeAllocSize](http://llvm.org/docs/doxygen/html/classllvm_1_1DataLayout.html#a1d6fcc02e91ba24510aba42660c90e29). Fixes: rust-lang#33266
libstd: correct the link to functions in io module documentation Currently the link refers to it's own section of the documentation rather than the list of functions generated by rustdoc. i.e. [this](http://doc.rust-lang.org/std/io/index.html#functions) should link to [this](http://doc.rust-lang.org/std/io/index.html#functions-1)
@bors r+ |
📌 Commit 638cf9f has been approved by |
bors
added a commit
that referenced
this pull request
May 3, 2016
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
create_dir
requests #33332, lexer: do not display char confusingly in error message #33334, docs: Changed docs forsize_of
to describe size as a stride offset #33335, libstd: correct the link to functions in io module documentation #33346