Rollup of 7 pull requests #115370
Merged
Rollup of 7 pull requests #115370
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
...to both compiler contributors and other rustc invokers. The previous error messaging was extremely unfriendly, and potentially both confusing and alarming. The entire modules is extracted into a new file to help ease of reading, and plenty of comments get layered in. The design of the messaging is focused on preventing the overall purpose of the output from being too opaque in common cases, so users understand why it is there. There's not an immediate need for it being actionable, but some suggestions are offered anyways.
This cleans up the formatting of the backtrace considerably, dodging the fact that a backtrace with recursion normally emits hundreds of lines. Instead, simply write repeated symbols, and add how many times the recursion occurred. Also, it makes it look more like the "normal" backtrace. Some fine details in the code are important for reducing the amount of possible panic branches.
First, we reuse the `MAX_FRAMES` constant. Co-authored-by: erikdesjardins <erikdesjardins@users.noreply.github.com> Then we choose an arbitrary recursion depth for the other case. In this case, I used 2d20. Honest.
…pected errors then also use the new helper in a few other places
Previously, the test code would emit E0615, thus revealing the existence of private methods that the programmer probably does not care about. Now it ignores their existence instead, producing error E0609 (no field). The motivating example is: ```rust let x = std::rc::Rc::new(()); x.inner; ``` which would previously mention the private method `Rc::inner()`, even though `Rc<T>` intentionally has no public methods so that it can be a transparent smart pointer for any `T`.
…er-message, r=pnkfelix Make SIGSEGV handler emit nicer backtraces This annotates the code heavily with comments to explain what is going on, for the benefit of other compiler contributors. The backtrace also emits appropriate comments to clarify, to a programmer who may not know why a bunch of file paths and hexadecimal blather was just dumped into stderr, what is going on. Finally, it detects cycles and uses their regularity to avoid repeating a bunch of text. The previous backtraces we were emitting was extremely unfriendly, potentially confusing, and often alarming, and this makes things almost "nice". We can't necessarily make them much nicer than this, because a signal handler must use "signal-safe" functions. This precludes conveniences like dynamic allocations. Fortunately, Rust's stdlib has allocation-free formatting, but it may hinder integrating this error with our localization middleware, as I wasn't able to clearly ascertain, at a glance, whether there was a zero-alloc path through it. r? `@Nilstrieb`
parser: not insert dummy field in struct Fixes rust-lang#114636 This PR eliminates the dummy field, initially introduced in rust-lang#113999, thereby enabling unrestricted use of `ident.unwrap()`. A side effect of this action is that we can only report the error of the first macro invocation field within the struct node. An alternative solution might be giving a virtual name to the macro, but it appears more complex.(rust-lang#114636 (comment)). Furthermore, if you think rust-lang#114636 (comment) is a better solution, feel free to close this PR.
miri/diagnostics: don't forget to print_backtrace when ICEing on unexpected errors This should fix the missing output encountered [here](rust-lang#115145 (comment)). r? `@saethlin`
… r=compiler-errors Make `get_return_block()` return `Some` only for HIR nodes in body Fixes rust-lang#114918 The issue occurred while compiling the following input: ```rust fn uwu() -> [(); { () }] { loop {} } ``` It was caused by the code below trying to suggest a missing return type which resulted in a const eval cycle: https://github.com/rust-lang/rust/blob/1bd043098e05839afb557bd7a2858cb09a4054ca/compiler/rustc_hir_typeck/src/fn_ctxt/suggestions.rs#L68-L75 The root cause was `get_return_block()` returning an `Fn` node for a node in the return type (i.e. the second `()` in the return type `[(); { () }]` of the input) although it is supposed to do so only for nodes that lie in the body of the function and return `None` otherwise (at least as per my understanding). The PR fixes the issue by fixing this behaviour of `get_return_block()`.
…=compiler-errors
suggest removing `impl` in generic trait bound position
rustc already does this recovery in type param position (`<T: impl Trait>` -> `<T: Trait>`).
This PR also adds that suggestion in trait bound position (e.g. `where T: impl Trait` or `trait Trait { type Assoc: impl Trait; }`)
new solver: handle edge case of a recursion limit of 0 Apparently a recursion limit of 0 is possible/valid/useful/used/cute, the more you know 🌟 . (It's somewhat interesting to me that the old solver seemingly handles this, and that the new solver currently requires a recursion limit of 2 here) r? `@compiler-errors.` Fixes rust-lang#115351.
…-errors Don't suggest adding parentheses to call an inaccessible method. Previously, code of this form would emit E0615 (attempt to use a method as a field), thus emphasizing the existence of private methods that the programmer probably does not care about. Now it ignores their existence instead, producing error E0609 (no field). The motivating example is: ```rust let x = std::rc::Rc::new(()); x.inner; ``` which would previously mention the private method `Rc::inner()`, even though `Rc<T>` intentionally has no public methods so that it can be a transparent smart pointer for any `T`. ```rust error[E0615]: attempted to take value of method `inner` on type `Rc<()>` --> src/main.rs:3:3 | 3 | x.inner; | ^^^^^ method, not a field | help: use parentheses to call the method | 3 | x.inner(); | ++ ``` With this change, it emits E0609 and no suggestion.
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=7 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 82c2eb48ee In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Aug 30, 2023
|
Finished benchmarking commit (7659abc): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 630.718s -> 630.791s (0.01%) |
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Aug 30, 2023
Fix bors missing a commit when merging rust-lang#115355 bors incorrectly merged an outdated version of PR rust-lang#115355 (via rollup rust-lang#115370): - it [recorded r+](rust-lang#115355 (comment)) as approving commit rust-lang@325b585, and thus merged the original revision rust-lang@7762ac7 - but the branch at the time was at commit rust-lang@eefa07d, so bors missed the `compiler/rustc_trait_selection/src/solve/search_graph/mod.rs` cleanup in commit rust-lang@0e1e964 😓 Thankfully the change that bors missed was small, and this new PR corrects the situation (as I'd rather avoid having confusing multiple merge commits of PR rust-lang#115355 in the git history) r? `@compiler-errors`
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Aug 31, 2023
Fix bors missing a commit when merging rust-lang#115355 bors incorrectly merged an outdated version of PR rust-lang#115355 (via rollup rust-lang#115370): - it [recorded r+](rust-lang#115355 (comment)) as approving commit rust-lang@325b585, and thus merged the original revision rust-lang@7762ac7 - but the branch at the time was at commit rust-lang@eefa07d, so bors missed the `compiler/rustc_trait_selection/src/solve/search_graph/mod.rs` cleanup in commit rust-lang@0e1e964 😓 Thankfully the change that bors missed was small, and this new PR corrects the situation (as I'd rather avoid having confusing multiple merge commits of PR rust-lang#115355 in the git history) r? ``@compiler-errors``
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.
Successful merges:
get_return_block()returnSomeonly for HIR nodes in body #115313 (Makeget_return_block()returnSomeonly for HIR nodes in body)implin generic trait bound position #115347 (suggest removingimplin generic trait bound position)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup