name the trait in ambiguous-associated-items fully qualified suggestion
We have the trait at this point, so we can name it in the error message, rather than using "Trait" as a (potentially confusing) placeholder.
Thanks to Yuki "@JohnTitor" Okushi for pointing out where to look (in the same file) for a closely related issue for ambiguous associated types (as opposed to items; that was #59225, except that one won't be
quite as easy to resolve, because we actually don't have the trait `DefId` at that point).
r? @petrochenkov
We have the trait at this point, so we can name it in the error
message, rather than using "Trait" as a (potentially confusing)
placeholder.
Thanks to Yuki "@JohnTitor" Okushi for pointing out where to look (in
the same file) for a closely related issue for ambiguous associated
types (as opposed to items; that was #59225, except that one won't be
quite as easy to resolve, because we actually don't have the trait
`DefId` at that point).
normalize use of backticks/lowercase in compiler messages for librustc_mir
normalize use of backticks/lowercase in compiler messages for librustc_mir
https://github.com/rust-lang/rust/issues/60532
r? @alexreg
Miri engine: support extra function (pointer) values
We want to add basic support for `dlsym` in Miri (needed to run the latest version of `getrandom`). For that to work, `dlsym` needs to return *something* that can be stored in a function pointer and later called.
So we add a new `ExtraFnVal` type to the `Machine` trait, and enable Miri's memory to associate allocation IDs with such values, so that `create_fn_alloc` and `get_fn` can work on *both* `Instance` (this is used for "normal" function pointers) and `ExtraFnVal`.
Cc @oli-obk
rustc_target: avoid negative register counts in the SysV x86_64 ABI.
Because `needed_{int,sse}` and `{int,sse}_regs` were only used with integer literals, they were inferred to `i32` and `{int,sse}_regs` could therefore be negative.
There was a check which prevented that, but *only* for aggregate arguments, not scalars.
Fixes#62350.
r? @nagisa or @rkruppe
Remove `compile-pass` from compiletest
This is a part of #62277.
Removes `compile-pass` from compiletest (and modify some tests' annotations).
r? @Centril
Create async version of the dynamic-drop test
Some of the tests in dynamic-drop have been cut:
* The tests that are just simpler versions of other tests - these tests are already fairly slow due to all of the unwinding and async functions have more control flow paths than normal functions.
* The union test - it's for an unstable feature that has an RFC to remove it.
* The generator test - there aren't async generators yet.
* The tests that show values being leaked - these can be added once the issue is fixed.
r? @Centril
cc #62121 @cramertj
Implement another internal lints
cc #49509
This adds ~~two~~ one internal lint~~s~~:
1. LINT_PASS_IMPL_WITHOUT_MACRO: Make sure, that the `{declare,impl}_lint_pass` macro is used to implement lint passes. cc #59669
2. ~~USAGE_OF_TYCTXT_AND_SPAN_ARGS: item 2 on the list in #49509~~
~~With 2. I wasn't sure, if this lint should be applied everywhere. That means a careful review of 0955835 would be great. Also 73fb9b4 allows this lint on some functions. Should I also apply this lint there?~~
TODO (not directly relevant for review):
- [ ] https://github.com/rust-lang/rust/pull/59316#discussion_r280186517 (not sure yet, if this works or how to query for `rustc_private`, since it's not in [`Features`](https://doc.rust-lang.org/nightly/nightly-rustc/syntax/feature_gate/struct.Features.html) 🤔 cc @eddyb)
- [x] https://github.com/rust-lang/rust/pull/61735#discussion_r292389870
- [x] Check explicitly for the `{declare,impl}_lint_pass!` macros
r? @oli-obk
Break out of the correct number of scopes in loops
We were incorrectly breaking out of one too many drop scopes when
generating MIR for loops and breakable blocks, resulting in use after
free and associated borrow checker warnings.
This wasn't noticed because the scope that we're breaking out of twice
is only used for temporaries that are created for adjustments applied to
the loop. Since loops generally propagate coercions to the `break`
expressions, the only case we see this is when the type of the loop is a
smart pointer to a trait object.
Closes#62312
Improve error span for async type inference error
Fixes#62382
Previously, we would point at the spawn of the 'await' expression,
instead of the actual expression with an unknown type.
We were incorrectly breaking out of one too many drop scopes when
generating MIR for loops and breakable blocks, resulting in use after
free and associated borrow checker warnings.
This wasn't noticed because the scope that we're breaking out of twice
is only used for temporaries that are created for adjustments applied to
the loop. Since loops generally propagate coercions to the `break`
expressions, the only case we see this is when the type of the loop is a
smart pointer to a trait object.
Migrate `compile-pass` annotations to `build-pass`
This is a part of #62277.
As a first step, the `compile-pass` tests are migrated to `build-pass`.
r? @cramertj
cc @Centril
wfcheck: resolve the type-vars in `AdtField` types
Normalization can leave some type-vars unresolved in its return type.
Make sure to resolve them so we have an infcx-independent type that can
be used with `needs_drop`.
Fixes#61402.
Closes#62212 - this PR fixes the root cause.
