-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 7 pull requests #111287
Rollup of 7 pull requests #111287
Conversation
This greatly simplifies how hard it is to set a custom bug report url; previously tools had to copy the entire hook implementation. - Switch clippy to the new hook This also adds a `extra_info` callback so clippy can include its own version number, which differs from rustc's. - Call `install_ice_hook` in rustfmt
When we're adding a method to a type DIE, we only want a DW_AT_declaration there, because LLVM LTO can't unify type definitions when a child DIE is a full subprogram definition. Now the subprogram definition gets added at the CU level with a specification link back to the abstract declaration.
…ts with custom items
Previously, incorrect spans were reported if inline assembly contained CRLF (Windows) line endings. Fixes rust-lang#110885
… r=lcnr Use fulfillment to check `Drop` impl compatibility Use an `ObligationCtxt` to ensure that a `Drop` impl does not have stricter requirements than the ADT that it's implemented for, rather than using a `SimpleEqRelation` to (more or less) syntactically equate predicates on an ADT with predicates on an impl. r? types ### Some background The old code reads: ```rust // An earlier version of this code attempted to do this checking // via the traits::fulfill machinery. However, it ran into trouble // since the fulfill machinery merely turns outlives-predicates // 'a:'b and T:'b into region inference constraints. It is simpler // just to look for all the predicates directly. ``` I'm not sure what this means, but perhaps in the 8 years since that this comment was written (cc rust-lang#23638) it's gotten easier to process region constraints after doing fulfillment? I don't know how this logic differs from anything we do in the `compare_impl_item` module. Ironically, later on it says: ```rust // However, it may be more efficient in the future to batch // the analysis together via the fulfill (see comment above regarding // the usage of the fulfill machinery), rather than the // repeated `.iter().any(..)` calls. ``` Also: * Removes `SimpleEqRelation` which was far too syntactical in its relation. * Fixes rust-lang#110557
Add Terminator conversion from MIR to SMIR, part #1 This adds internal MIR TerminatorKind to SMIR Terminator conversion. r? ```@oli-obk```
…aber Fix spans in LLVM-generated inline asm errors Previously, incorrect spans were reported if inline assembly contained CRLF (Windows) line endings. Fixes rust-lang#110885
Make the BUG_REPORT_URL configurable by tools This greatly simplifies how hard it is to set a custom bug report url; previously tools had to copy the entire hook implementation. I haven't changed clippy in case they want to make the change upstream instead of the subtree, but I'm happy to do so here if the maintainers want - cc ````@rust-lang/clippy```` Fixes rust-lang#109486.
…michaelwoerister debuginfo: split method declaration and definition When we're adding a method to a type DIE, we only want a DW_AT_declaration there, because LLVM LTO can't unify type definitions when a child DIE is a full subprogram definition. Now the subprogram definition gets added at the CU level with a specification link back to the abstract declaration. Both GCC and Clang write debuginfo this way for C++ class methods. Fixes rust-lang#109730. Fixes rust-lang#109934.
…mpiler-errors add hint for =< as <= Adds a compiler hint for when `=<` is typed instead of `<=` Example hint: ```rust fn foo() { if 1 =< 3 { println!("Hello, World!"); } } ``` ``` error: expected type, found `3` --> main.rs:2:13 | 2 | if 1 =< 3 { | -- ^ expected type | | | help: did you mean: `<=` ``` This PR only emits the suggestion if there is no space between the `=` and `<`. This hopefully narrows the scope of when this error is emitted, however this still allows this error to be emitted in cases such as this: ``` error: expected expression, found `;` --> main.rs:2:18 | 2 | if 1 =< [i32;; 3]>::hello() { | -- ^ expected expression | | | help: did you mean: `<=` ``` Which could be a good reason not to merge since I haven't been able to think of any other ways of narrowing the scope of this diagnostic. closes rust-lang#111128
… r=cjgillot More robust debug assertions for `Instance::resolve` on built-in traits with non-standard trait items In rust-lang#111264, a user added a new item to the `Future` trait, but the code in [`resolve_associated_item`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_ty_utils/instance/fn.resolve_associated_item.html) implicitly assumes that the `Future` trait is defined with only one method (`Future::poll`) and treats the generator body as the implementation of that method. This PR adds some debug assertions to make sure that that new methods defined on `Future`/`Generator`/etc. don't accidentally resolve to the wrong item when they are added, and adds a helpful comment guiding a compiler dev (or curious `#![no_core]` user) to what must be done to support adding new associated items to these built-in implementations. I am open to discuss whether a test should be added, but I chose against it because I opted to make these `bug!()`s instead of, e.g., diagnostics or fatal errors. Arguably it doesn't need a test because it's not a bug that can be triggered by an end user, and internal-facing misuses of core kind of touch on rust-lang/compiler-team#620 -- however, I think the assertions I added in this PR are still a very useful way to make sure this bug doesn't waste debugging resources down the line. Fixes rust-lang#111264
@bors r+ rollup=never p=7 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR: previous master: 333b920fee In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (905d5a3): comparison URL. Overall result: ❌ regressions - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
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.
CyclesResultsThis 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.
Binary sizeResultsThis 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.
Bootstrap: 656.005s -> 653.763s (-0.34%) |
This is our standard bimodality kicking in on the affected benchmarks, dropping regression label. |
Successful merges:
Drop
impl compatibility #110577 (Use fulfillment to checkDrop
impl compatibility)Instance::resolve
on built-in traits with non-standard trait items #111279 (More robust debug assertions forInstance::resolve
on built-in traits with non-standard trait items)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup