Match on lang item kind instead of using an if/else chain
Similar to how the new solver does this. Just noticed while I was adding a new entry to the chain 😆
typeck: catch `continue`s pointing to blocks
This taints the typeck results with errors if a `continue` is found not pointing to a loop.
A few things were going wrong here. First, since this wasn't caught in typeck, we'd end up building the THIR and then running liveness lints on ill-formed HIR. Since liveness assumes all `continue`s point to loops, it wasn't setting a live node for the `continue`'s destination. There was a fallback for if it couldn't retrieve that live node, but it was faulty; it would create a new live node to represent an erroneous state after the analysis's RWU table had already been built. This would ICE if the new live node was used in operations, such as merging results from the arms of a match. I've removed this error-recovery since it was buggy, and we should really catch bad labels before liveness.
I've also replaced an outdated comment about when liveness lints are run. At this point, I think the call to `check_liveness` could be moved elsewhere, but if it can be run when the typeck results are tainted by errors, it'll need some slight refactoring so it can bail out in that case. In lieu of that, I've added an assert.
Fixes#113379Fixes#121623
Allow trailing comma after argument in query definition
Don't catastrophically fail the query macro if you put a comma after your query key!
r? oli-obk
Suggest use "{}", self.x instead of {self.x} when resolve x as field of `self`
Fixes#141136
Changes can be seen in the second commit: 9de7fff0d8
r? compiler
collect doc alias as tips during resolution
Close#124273
Collect the symbol in the doc alias attributes and provide a tip when a match is found.
r? `@estebank`
This taints the typeck results with errors if a `continue` is found not
pointing to a loop, which fixes an ICE.
A few things were going wrong here. First, since this wasn't caught in
typeck, we'd end up building the THIR and then running liveness lints on
ill-formed HIR. Since liveness assumes all `continue`s point to loops,
it wasn't setting a live node for the `continue`'s destination. However,
the fallback for this was faulty; it would create a new live node to
represent the erroneous state after the analysis's RWU table had already
been built. This would ICE if the new live node was used in operations,
such as merging results from the arms of a match. I've removed this
error-recovery since it was buggy, and we should really catch bad labels
before liveness.
I've also replaced an outdated comment about when liveness lints are
run. At this point, I think the call to `check_liveness` could be moved
elsewhere, but if it can be run when the typeck results are tainted by
errors, it'll need some slight refactoring so it can bail out in that
case. In lieu of that, I've added an assertion.
Add TRACING_ENABLED to Machine and add enter_trace_span!()
This PR adds the necessary infrastructure to make it possible to do tracing calls from within `rustc_const_eval` when running Miri, while making sure they don't impact the performance of normal compiler execution. This is done by adding a `const` boolean to `Machine`, false by default, but that will be set to true in Miri only. The tracing macro `enter_trace_span!()` checks if it is true before doing anything, and since the value of a `const` is known at compile time, if it it false it the whole tracing call should be optimized out.
I will soon open further PRs to add tracing macro calls similar to this one, so that afterwards it will be possible to learn more about Miri's time spent in the various interpretation steps:
```rs
let _guard = enter_trace_span!(M, "eval_statement", "{:?}", stmt);
```
r? `@RalfJung`
`gather_locals`: only visit guard pattern guards when checking the guard
When checking a pattern with guards in it, `GatherLocalsVisitor` will visit both the pattern (when type-checking the let, arm, or param containing it) and local declarations in the guard expression (when checking the guard itself). This keeps it from visiting the guard when visiting the pattern, since otherwise it would gather locals from the guard twice, which would lead to a delayed bug: "evaluated expression more than once".
Tracking issue for guard patterns: #129967
Warning added when dependency crate has async drop types, and the feature is disabled
In continue of https://github.com/rust-lang/rust/pull/141031.
When dependency crate has non-empty `adt_async_destructor` table in metadata, and `async_drop` feature is disabled for local crate, warning will be emitted.
Test `dependency-dropped` has two revisions - with and without feature enabled. With feature enabled, async drop for dropee is executed ("Async drop" printed). Without the feature enabled, sync drop is executed ("Sync drop" printed) and warning is emitted.
Warning example:
```
warning: found async drop types in dependecy `async_drop_dep`, but async_drop feature is disabled for `dependency_dropped`
--> $DIR/dependency-dropped.rs:7:1
|
LL | #![cfg_attr(with_feature, feature(async_drop))]
| ^
|
= help: if async drop type will be dropped in a crate without `feature(async_drop)`, sync Drop will be used
```
Resolved issue with mismatched types triggering ICE in certain scenarios
## Background
The function `annotate_mut_binding_to_immutable_binding` called in `emit_coerce_suggestions` performs a type comparison between the `expected` and `found` types from `ExpectedFound` in the `TypeError`. This can fail if the `found` type contains a region variable that's been rolled back.
## What is being changed?
This updates `annotate_mut_binding_to_immutable_binding` to use `expr_ty` and `expected` from the parent function instead of the types from the `TypeError`. This sidesteps the issue of using `found` from `TypeError` which may leak lingering inference region variables.
This does change the diagnostic behavior to _only_ support cases where the expected outermost type is `&T`, but that seems to be the intended functionality.
Also fixed the example in the `annotate_mut_binding_to_immutable_binding` rustdocs.
r? rust-lang/types
Fixes#140823
When checking a pattern with guards in it, `GatherLocalsVisitor` will
visit both the pattern (when type-checking the let, arm, or param
containing it) and the guard expression (when checking the guard
itself). This keeps it from visiting the guard when visiting the
pattern, since otherwise it would gather locals from the guard twice,
which would lead to a delayed bug: "evaluated expression more than
once".
Rollup of 6 pull requests
Successful merges:
- #131200 (Handle `rustc_query_system` cases of `rustc::potential_query_instability` lint)
- #141244 (windows: document that we rely on an undocumented property of GetUserProfileDirectoryW)
- #141247 (skip compiler tools sanity checks on certain commands)
- #141248 (fix data race in ReentrantLock fallback for targets without 64bit atomics)
- #141249 (introduce common macro for `MutVisitor` and `Visitor` to dedup code)
- #141253 (Warning added when dependency crate has async drop types, and the feature is disabled)
r? `@ghost`
`@rustbot` modify labels: rollup
Warning added when dependency crate has async drop types, and the feature is disabled
In continue of https://github.com/rust-lang/rust/pull/141031.
When dependency crate has non-empty `adt_async_destructor` table in metadata, and `async_drop` feature is disabled for local crate, warning will be emitted.
Test `dependency-dropped` has two revisions - with and without feature enabled. With feature enabled, async drop for dropee is executed ("Async drop" printed). Without the feature enabled, sync drop is executed ("Sync drop" printed) and warning is emitted.
Warning example:
```
warning: found async drop types in dependecy `async_drop_dep`, but async_drop feature is disabled for `dependency_dropped`
--> $DIR/dependency-dropped.rs:7:1
|
LL | #![cfg_attr(with_feature, feature(async_drop))]
| ^
|
= help: if async drop type will be dropped in a crate without `feature(async_drop)`, sync Drop will be used
```
introduce common macro for `MutVisitor` and `Visitor` to dedup code
helps with #127615.
I can do everything in one go but I figured it might be worth it to open a PR first for vibeck.
r? oli-obk
dladdr cannot leave dli_fname to be null
There are two places in the repo calling `dladdr`, and they are inconsistent wrt their assumption of whether the `dli_fname` field can be null. Let's make them consistent. I see nothing in the docs that allows it to be null, but just to be on the safe side let's make this an assertion so hopefully we get a report if that ever happens.
coverage: Detect unused local file IDs to avoid an LLVM assertion
Each function's coverage metadata contains a *local file table* that maps local file IDs (used by the function's mapping regions) to global file IDs (shared by all functions in the same CGU).
LLVM requires all local file IDs to have at least one mapping region, and has an assertion that will fail if it detects a local file ID with no regions. To make sure that assertion doesn't fire, we need to detect and skip functions whose metadata would trigger it.
(This can't actually happen yet, because currently all of a function's spans must belong to the same file and expansion. But this will be an important edge case when adding expansion region support.)
make `rustc_attr_parsing` less dominant in the rustc crate graph
It has/had a glob re-export of `rustc_attr_data_structures`, which is a crate much lower in the graph, and a lot of crates were using it *just* (or *mostly*) for that re-export, while they can rely on `rustc_attr_data_structures` directly.
Previous graph:
Graph with this PR:
The first commit keeps the re-export, and just changes the dependency if possible. The second commit is the "breaking change" which removes the re-export, and "explicitly" adds the `rustc_attr_data_structures` dependency where needed. It also switches over some src/tools/*.
The second commit is actually a lot more involved than I expected. Please let me know if it's a better idea to back it out and just keep the first commit.
fix autodiff macro on generic functions
heloo there!
This short PR allows applying the `autodiff` macro to generic functions like this one.
It only touches the frontend part, since the `rustc_autodiff` macro can already handle generics.
```rust
#[autodiff(d_square, Reverse, Duplicated, Active)]
fn square<T: std::ops::Mul<Output = T> + Copy>(x: &T) -> T {
*x * *x
}
```
Thanks to Manuel for creating an issue on this. For more information on this see #140032
r? `@ZuseZ4`
As always: thanks for any piece of feedback!!
Fixes: #140032
Tracking issue for autodiff: https://github.com/rust-lang/rust/issues/124509
gvn: avoid creating overlapping assignments
Quick fix#141038, as I couldn't find a way to avoid in-place modification. I'm considering handling all `ravlue` modifications within the `visit_statement` function.
r? mir-opt
bump windows crate for compiler,bootstrap and tools
This dedupes crate versions. For `x86_64-pc-windows-msvc` stage1 cuts few kb from `rustc_driver.dll`, nice.
Return value of coroutine_layout fn changed to Result with LayoutError
Continue of https://github.com/rust-lang/rust/pull/140902:
`coroutine_layout` fn is now returns `Result` with `LayoutError` to have consistent error with `layout_of_uncached`.
`async_drop_coroutine_layout` fn is now return `LayoutError::TooGeneric` in case of not-fully-specialized `async_drop_in_place<T>::{closure}` coroutine.
name resolution for guard patterns
This PR provides an initial implementation of name resolution for guard patterns [(RFC 3637)](https://github.com/rust-lang/rfcs/blob/master/text/3637-guard-patterns.md). This does not change the requirement that the bindings on either side of an or-pattern must be the same [(proposal here)](https://github.com/rust-lang/rfcs/blob/master/text/3637-guard-patterns.md#allowing-mismatching-bindings-when-possible); the code that handles that is separate from what this PR touches, so I'm saving it for a follow-up.
On a technical level, this separates "collecting the bindings in a pattern" (which was already done for or-patterns) from "introducing those bindings into scope". I believe the approach used here can be extended straightforwardly in the future to work with `if let` guard patterns, but I haven't tried it myself since we don't allow those yet.
Tracking issue for guard patterns: #129967
cc ``@Nadrieril``
