There are several places in `rustc_middle` that check for an empty
lifetime name. These checks appear to be totally unnecessary, because
empty lifetime names aren't produced here. (Empty lifetime names *are*
possible in `hir::Lifetime`. Perhaps there was some confusion between
it and the `rustc_middle` types?)
This commit removes the `kw::Empty` checks.
Batch mark waiters as unblocked when resuming in the deadlock handler
This fixes a race when resuming multiple threads to resolve query cycles. This now marks all threads as unblocked before resuming any of them. Previously if one was resumed and marked as unblocked at a time. The first thread resumed could fall asleep then Rayon would detect a second false deadlock. Later the initial deadlock handler thread would resume further threads.
This also reverts the workaround added in https://github.com/rust-lang/rust/pull/137731.
cc `@SparrowLii` `@lqd`
Stabilize `#![feature(precise_capturing_in_traits)]`
# Precise capturing (`+ use<>` bounds) in traits - Stabilization Report
Fixes https://github.com/rust-lang/rust/issues/130044.
## Stabilization summary
This report proposes the stabilization of `use<>` precise capturing bounds in return-position impl traits in traits (RPITITs). This completes a missing part of [RFC 3617 "Precise capturing"].
Precise capturing in traits was not ready for stabilization when the first subset was proposed for stabilization (namely, RPITs on free and inherent functions - https://github.com/rust-lang/rust/pull/127672) since this feature has a slightly different implementation, and it hadn't yet been implemented or tested at the time. It is now complete, and the type system implications of this stabilization are detailed below.
## Motivation
Currently, RPITITs capture all in-scope lifetimes, according to the decision made in the ["lifetime capture rules 2024" RFC](https://rust-lang.github.io/rfcs/3498-lifetime-capture-rules-2024.html#return-position-impl-trait-in-trait-rpitit). However, traits can be designed such that some lifetimes in arguments may not want to be captured. There is currently no way to express this.
## Major design decisions since the RFC
No major decisions were made. This is simply an extension to the RFC that was understood as a follow-up from the original stabilization.
## What is stabilized?
Users may write `+ use<'a, T>` bounds on their RPITITs. This conceptually modifies the desugaring of the RPITIT to omit the lifetimes that we would copy over from the method. For example,
```rust
trait Foo {
fn method<'a>(&'a self) -> impl Sized;
// ... desugars to something like:
type RPITIT_1<'a>: Sized;
fn method_desugared<'a>(&'a self) -> Self::RPITIT_1<'a>;
// ... whereas with precise capturing ...
fn precise<'a>(&'a self) -> impl Sized + use<Self>;
// ... desugars to something like:
type RPITIT_2: Sized;
fn precise_desugared<'a>(&'a self) -> Self::RPITIT_2;
}
```
And thus the GAT doesn't name `'a`. In the compiler internals, it's not implemented exactly like this, but not in a way that users should expect to be able to observe.
#### Limitations on what generics must be captured
Currently, we require that all generics from the trait (including the `Self`) type are captured. This is because the generics from the trait are required to be *invariant* in order to do associated type normalization.
And like regular precise capturing bounds, all type and const generics in scope must be captured.
Thus, only the in-scope method lifetimes may be relaxed with this syntax today.
## What isn't stabilized? (a.k.a. potential future work)
See section above. Relaxing the requirement to capture all type and const generics in scope may be relaxed when https://github.com/rust-lang/rust/issues/130043 is implemented, however it currently interacts with some underexplored corners of the type system (e.g. unconstrained type bivariance) so I don't expect it to come soon after.
## Implementation summary
This functionality is implemented analogously to the way that *opaque type* precise capturing works.
Namely, we currently use *variance* to model the capturedness of lifetimes. However, since RPITITs are anonymous GATs instead of opaque types, we instead modify the type relation of GATs to consider variances for RPITITs (along with opaque types which it has done since https://github.com/rust-lang/rust/pull/103491).
30f168ef81/compiler/rustc_middle/src/ty/util.rs (L954-L976)30f168ef81/compiler/rustc_type_ir/src/relate.rs (L240-L244)
Using variance to model capturedness is an implementation detail, and in the future it would be desirable if opaques and RPITITs simply did not include the uncaptured lifetimes in their generics. This can be changed in a forwards-compatible way, and almost certainly would not be observable by users (at least not negatively, since it may indeed fix some bugs along the way).
## Tests
* Test that the lifetime isn't actually captured: `tests/ui/impl-trait/precise-capturing/rpitit.rs` and `tests/ui/impl-trait/precise-capturing/rpitit-outlives.rs` and `tests/ui/impl-trait/precise-capturing/rpitit-outlives-2.rs`.
* Technical test for variance computation: `tests/ui/impl-trait/in-trait/variance.rs`.
* Test that you must capture all trait generics: `tests/ui/impl-trait/precise-capturing/forgot-to-capture-type.rs`.
* Test that you cannot capture more than what the trait specifies: `tests/ui/impl-trait/precise-capturing/rpitit-captures-more-method-lifetimes.rs` and `tests/ui/impl-trait/precise-capturing/rpitit-impl-captures-too-much.rs`.
* Undercapturing (refinement) lint: `tests/ui/impl-trait/in-trait/refine-captures.rs`.
### What other unstable features may be exposed by this feature?
I don't believe that this exposes any new unstable features indirectly.
## Remaining bugs and open issues
Not aware of any open issues or bugs.
## Tooling support
Rustfmt: ✅ Supports formatting `+ use<>` everywhere.
Clippy: ✅ No support needed, unless specific clippy lints are impl'd to care for precise capturing itself.
Rustdoc: ✅ Rendering `+ use<>` precise capturing bounds is supported.
Rust-analyzer: ✅ Parser support, and then lifetime support isn't needed https://github.com/rust-lang/rust/pull/138128#issuecomment-2705292494 (previous: ~~❓ There is parser support, but I am unsure of rust-analyzer's level of support for RPITITs in general.~~)
## History
Tracking issue: https://github.com/rust-lang/rust/issues/130044
* https://github.com/rust-lang/rust/pull/131033
* https://github.com/rust-lang/rust/pull/132795
* https://github.com/rust-lang/rust/pull/136554
add FCW to warn about wasm ABI transition
See https://github.com/rust-lang/rust/issues/122532 for context: the "C" ABI on wasm32-unk-unk will change. The goal of this lint is to warn about any function definition and calls whose behavior will be affected by the change. My understanding is the following:
- scalar arguments are fine
- including 128 bit types, they get passed as two `i64` arguments in both ABIs
- `repr(C)` structs (recursively) wrapping a single scalar argument are fine (unless they have extra padding due to over-alignment attributes)
- all return values are fine
`@bjorn3` `@alexcrichton` `@Manishearth` is that correct?
I am making this a "show up in future compat reports" lint to maximize the chances people become aware of this. OTOH this likely means warnings for most users of Diplomat so maybe we shouldn't do this?
IIUC, wasm-bindgen should be unaffected by this lint as they only pass scalar types as arguments.
Tracking issue: https://github.com/rust-lang/rust/issues/138762
Transition plan blog post: https://github.com/rust-lang/blog.rust-lang.org/pull/1531
try-job: dist-various-2
Visitors track whether an assoc item is in a trait impl or an inherent impl
`AssocCtxt::Impl` now contains an `of_trait` field. This allows ast lowering and nameres to not have to track whether we're in a trait impl or an inherent impl.
Fix autofix for `self` and `self as …` in `unused_imports` lint
This fixes two problems with the autofixes for the `unused_imports` lint:
- `use std::collections::{HashMap, self as coll};` would suggest, when `HashMap` is unused, the incorrect `use std::collections::self as coll;` which does not compile.
- `use std::borrow::{self, Cow};` would suggest, when `self` is unused, `use std::borrow::{Cow};`, which contains unnecessary brackets.
The first problem was reported in rust-lang/rust-clippy#14450, the second found while fixing the first one.
Fix#133750
(thanks to `@richardsamuels` for spotting the duplicate)
coverage: Separate span-extraction from unexpansion
Historically, coverage instrumentation has relied on eagerly “unexpanding” MIR spans back to ancestor spans that have the same context as the function body, and lie within that body. Doing so makes several subsequent operations more straightforward.
In order to support expansion regions, we need to stop doing that, and handle layers of macro-expansion more explicitly. This PR takes a step in that direction, by deferring some of the unexpansion steps, and concentrating them in one place (`spans::extract_refined_covspans`).
Unexpansion still takes place as before, but these changes will make it easier to experiment with expansion-aware coverage instrumentation.
Abort in deadlock handler if we fail to get a query map
Resolving query cycles requires the complete active query map, or it may miss query cycles. We did not check that the map is completely constructed before. If there is some error collecting the map, something has gone wrong already. This adds a check to abort/panic if we fail to construct the complete map.
This can help differentiate errors from the `deadlock detected` case if constructing query map has errors in practice.
An `Option` is not used for `collect_active_jobs` as the panic handler can still make use of a partial map.
cg_llvm: Reduce the visibility of types, modules and using declarations in `rustc_codegen_llvm`.
Final part of #135502
Reduces the visibility of types, modules and using declarations in the `rustc_codegen_llvm` to private or `pub(crate)` where possible, and marks unused fields and enum entries with `#[expect(dead_code)]`.
r? Zalathar
StructLiteralNeedingParens is no longer reachable always giving
precedence to StructLiteralNotAllowedHere.
As an aside: The former error struct shouldn't've existed in the
first place. We should've just used the latter in this branch.
Remove InstanceKind::generates_cgu_internal_copy
This PR should not contain any behavior changes. Before this PR, the logic for selecting instantiation mode is spread across all of
* `instantiation_mode`
* `cross_crate_inlinable`
* `generates_cgu_internal_copy`
* `requires_inline`
The last two of those functions are not well-designed. The function that actually decides if we generate a CGU-internal copy is `instantiation_mode`, _not_ `generates_cgu_internal_copy`. The function `requires_inline` documents that it is about the LLVM `inline` attribute and that it is a hint. The LLVM attribute is called `inlinehint`, this function is also used by other codegen backends, and since it is part of instantiation mode selection it is *not* a hint.
The goal of this PR is to start cleaning up the logic into a sequence of checks that have a more logical flow and are easier to customize in the future (to do things like improve incrementality or improve optimizations without causing obscure linker errors because you forgot to update another part of the compiler).
Add a helper for building an owner id in ast lowering
Just some deduplication of owner-id creations. Will also help me later split up ast lowering into per-owner queries, as it won't be possible anymore to go from a NodeId to a DefId of an owner without doing extra work to check whether we have an owner id. So I'd just do that in the new `owner_id` function and keep the `local_def_id` function free of that logic
Fix/tweak some tests in new solver
Bunch of miscellaneous new solver tweaks that I found from the failing tests. Can split these out, but they all seemed small enough to not warrant separate PRs.
r? lcnr
The existing code produces `Some(kw::Empty)` for these invalid forms:
- a non-name-value, e.g. `#[rustc_allowed_through_unstable_modules]`
- a non-string arg, e.g. `#[rustc_allowed_through_unstable_modules = 3]`
The new code avoids the `kw::Empty` and is a little shorter. It will
produce `None` in those cases, which means E0789 won't be produced if
the `stable` attribute is missing for these invalid forms. This doesn't
matter, because these invalid forms will trigger an "malformed
`rustc_allowed_through_unstable_modules` attribute" anyway.
This way, `None` represents "crate root without a name" instead of
`kw::Empty`. This changes makes it impossible to forget to handle the
exceptional case.
Lower to a memset(undef) when Rvalue::Repeat repeats uninit
Fixes https://github.com/rust-lang/rust/issues/138625.
It is technically correct to just do nothing. But if we actually do nothing, we may miss that this is de-initializing something, so instead we just lower to a single memset that writes undef. This is still superior to the memcpy loop, in both quality of code we hand to the backend and LLVM's final output.
Lower BinOp::Cmp to llvm.{s,u}cmp.* intrinsics
Lowers `mir::BinOp::Cmp` (`three_way_compare` intrinsic) to the corresponding LLVM `llvm.{s,u}cmp.i8.*` intrinsics.
These are the intrinsics mentioned in https://github.com/rust-lang/rust/pull/118310, which are now available in LLVM 19.
I couldn't find any follow-up PRs/discussions about this, please let me know if I missed something.
r? `@scottmcm`
`with_scope` is only ever used for ast modules
Thus I renamed it to match other similar functions (`with_mod_rib`) and made it panic if used on non-modules
match lowering cleanup: remove unused unsizing logic from `non_scalar_compare`
Since array and slice constants are now translated to array and slice patterns, `non_scalar_compare` is only used for string comparisons. This specializes it to strings, renames it, and removes the unused array-unsizing logic.
This also updates the doc comments for `thir::PatKind::Constant` and `TestKind::Eq`, which referred to them being used for slice references.
r? ````@oli-obk````
I saw someone post a code sample that contained these two attributes,
which immediately made me suspicious.
My suspicions were confirmed when I did a small test and checked the
compiler source code to confirm that in these cases, `#[inline]` is
indeed ignored (because you can't exactly `LocalCopy`an unmangled symbol
since that would lead to duplicate symbols, and doing a mix of an
unmangled `GloballyShared` and mangled `LocalCopy` instantiation is too
complicated for our current instatiation mode logic, which I don't want
to change right now).
So instead, emit the usual unused attribute lint with a message saying
that the attribute is ignored in this position.
I think this is not 100% true, since I expect LLVM `inlinehint` to still
be applied to such a function, but that's not why people use this
attribute, they use it for the `LocalCopy` instantiation mode, where it
doesn't work.
This fixes two problems with the autofixes for the `unused_imports`
lint:
- `use std::collections::{HashMap, self as coll};` would suggest, when
`HashMap` is unused, the incorrect `use std::collections::self as coll;`
which does not compile.
- `use std::borrow::{self, Cow};` would suggest, when `self` is unused,
`use std::borrow::{Cow};`, which contains unnecessary brackets.
Optimize hash map operations in the query system
This optimizes hash map operations in the query system by explicitly passing hashes and using more optimal operations. `find_or_find_insert_slot` in particular saves a hash table lookup over `entry`. It's not yet available in a safe API, but will be in https://github.com/rust-lang/hashbrown/pull/466.
<table><tr><td rowspan="2">Benchmark</td><td colspan="1"><b>Before</b></th><td colspan="2"><b>After</b></th></tr><tr><td align="right">Time</td><td align="right">Time</td><td align="right">%</th></tr><tr><td>🟣 <b>clap</b>:check</td><td align="right">1.6189s</td><td align="right">1.6129s</td><td align="right"> -0.37%</td></tr><tr><td>🟣 <b>hyper</b>:check</td><td align="right">0.2353s</td><td align="right">0.2337s</td><td align="right"> -0.67%</td></tr><tr><td>🟣 <b>regex</b>:check</td><td align="right">0.9344s</td><td align="right">0.9289s</td><td align="right"> -0.59%</td></tr><tr><td>🟣 <b>syn</b>:check</td><td align="right">1.4693s</td><td align="right">1.4652s</td><td align="right"> -0.28%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check</td><td align="right">5.6606s</td><td align="right">5.6439s</td><td align="right"> -0.30%</td></tr><tr><td>Total</td><td align="right">9.9185s</td><td align="right">9.8846s</td><td align="right"> -0.34%</td></tr><tr><td>Summary</td><td align="right">1.0000s</td><td align="right">0.9956s</td><td align="right"> -0.44%</td></tr></table>
r? `@cjgillot`
They're dodgy, covering all the keywords, including weak ones, and
edition-specific ones without considering the edition. They have a
single use in rustfmt. This commit changes that use to
`is_reserved_ident`, which is a much more widely used alternative and is
good enough, judging by the lack of effect on the test suite.
Tweaks to writeback and `Obligation -> Goal` conversion
Each of these commits are self-contained, but are prerequisites that I'd like to land before #138845, which still needs some cleaning.
The ""most controversial"" one is probably [Explicitly don't fold coroutine obligations in writeback](e7d27bae27), which I prefer because I think using `fold_predicate` to control against not normalizing predicates seems... easy to mess up 🤔, and we could have *other things* that we don't want to normalize.
Explicitly noting whether we want `resolve` to normalize is a lot clearer (and currently in writeback is limited to resolving stalled coroutine obligations), since we can attach it to a comment that explains *why*.
Cache current_dll_path output
Computing the current dll path is somewhat expensive relative to other work when compiling `fn main() {}` as `dladdr` needs to iterate over the symbol table of librustc_driver.so until it finds a match.
Don't attempt to export compiler-builtins symbols from rust dylibs
They are marked with hidden visibility to prevent them from getting exported, so we shouldn't ask the linker to export them anyway. The only thing that does it cause a warning on macOS.
Part of https://github.com/rust-lang/rust/issues/136096
cc `@jyn514`
Tweak type flags, fix missing flags from coroutine kind ty
Firstly, make sure we visit the coroutine kind ty. Since this kind ty is either infer (before upvar computation), or `()` or `i8`/`i16`/`i32`, this isn't really that big of a deal, since other types in the coroutine will also be infer, so we're not misreporting `ty.has_infer()` or anything, but it's still wrong not to do this.
Furthermore, remove `HAS_TY_COROUTINE`, since nobody used it, and also remove special casing for `STILL_FURTHER_SPECIALIZABLE` since it's likely not important anymore? I have a vague recollection that it was important for polymorphization(?), but no tests seem to rely on this behavior.
r? lcnr or reassign
Add unstable `--print=supported-crate-types` option
MCP: https://github.com/rust-lang/compiler-team/issues/836
Tracking issue: https://github.com/rust-lang/rust/issues/138640
### Test coverage
Two tests:
1. `tests/ui/print-request/stability.rs` to check that `--print=supported-crate-types` is `-Zunstable-options`-gated
2. `tests/ui/print-request/supported-crate-types.rs` is added as a basic smoke test. Observe that the compiler stdout corresponds to the below *Example output* section (e.g. `proc-macro` is unsupported on `wasm32-unknown-unknown` currently).
### Example output
<details>
<summary>For `x86_64-unknown-linux-gnu`</summary>
Notice the presence of `{c,}dylib` and `proc-macro`:
```
bin
cdylib
dylib
lib
proc-macro
rlib
staticlib
```
</details>
<details>
<summary>For `wasm32-unknown-unknown`</summary>
Notice the absence of `dylib` and `proc-macro`:
```
bin
cdylib
lib
rlib
staticlib
```
</details>
<details>
<summary>For `x86_64-unknown-linux-musl`</summary>
Notice the absence of `{c,}dylib` but presence of `proc-macro`:
```
bin
lib
proc-macro
rlib
staticlib
```
</details>
### Documentation
I added an entry in the unstable book's print request section to document this `supported-crate-types` print request.
### Unresolved questions
- [ ] (Name bikeshedding) is `supported-crate-types` a good name for the print request? I'm inclined to say it's good enough for an unstable print request, but may be worth revisiting at stabilization time.
### Stability
This print request being added is *unstable* in this PR. A separate stabilization PR following the usual compiler flag stabilization procedure should be filed for stabilization after some baking time.
### Review remarks
Best reviewed commit-by-commit.
r? compiler
Move some driver code around
`--emit mir`, `#[rustc_symbol_name]` and `#[rustc_def_path]` now run before codegen and thus work even if codegen fails. This can help with debugging.
Reduce FormattingOptions to 64 bits
This is part of https://github.com/rust-lang/rust/issues/99012
This reduces FormattingOptions from 6-7 machine words (384 bits on 64-bit platforms, 224 bits on 32-bit platforms) to just 64 bits (a single register on 64-bit platforms).
Before:
```rust
pub struct FormattingOptions {
flags: u32, // only 6 bits used
fill: char,
align: Option<Alignment>,
width: Option<usize>,
precision: Option<usize>,
}
```
After:
```rust
pub struct FormattingOptions {
/// Bits:
/// - 0-20: fill character (21 bits, a full `char`)
/// - 21: `+` flag
/// - 22: `-` flag
/// - 23: `#` flag
/// - 24: `0` flag
/// - 25: `x?` flag
/// - 26: `X?` flag
/// - 27: Width flag (if set, the width field below is used)
/// - 28: Precision flag (if set, the precision field below is used)
/// - 29-30: Alignment (0: Left, 1: Right, 2: Center, 3: Unknown)
/// - 31: Always set to 1
flags: u32,
/// Width if width flag above is set. Otherwise, always 0.
width: u16,
/// Precision if precision flag above is set. Otherwise, always 0.
precision: u16,
}
```
Since array and slice constants are now lowered to array and slice
patterns, `non_scalar_compare` was only called for string comparisons.
This specializes it to strings, renames it, and removes the unused
array-unsizing logic.
This also updates some outdated doc comments.
An assignment such as
(a, b) = (b, c);
desugars to the HIR
{ let (lhs, lhs) = (b, c); a = lhs; b = lhs; };
The repeated `lhs` leads to multiple Locals assigned to the same DILocalVariable. Rather than
attempting to fix that, get rid of the debug info for these bindings that don't even exist
in the program to begin with.
Fixes#138198
Avoid no-op unlink+link dances in incr comp
Incremental compilation scales quite poorly with the number of CGUs. This PR improves one reason for that.
The incr comp process hard-links all the files from an old session into a new one, then it runs the backend, which may just hard-link the new session files into the output directory. Then codegen hard-links all the output files back to the new session directory.
This PR (perhaps unimaginatively) fixes the silliness that ensues in the last step. The old `link_or_copy` implementation would be passed pairs of paths which are already the same inode, then it would blindly delete the destination and re-create the hard-link that it just deleted. This PR lets us skip both those operations. We don't skip the other two hard-links.
`cargo +stage1 b && touch crates/core/main.rs && strace -cfw -elink,linkat,unlink,unlinkat cargo +stage1 b` before and then after on `ripgrep-13.0.0`:
```
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
52.56 0.024950 25 978 485 unlink
34.38 0.016318 22 727 linkat
13.06 0.006200 24 249 unlinkat
------ ----------- ----------- --------- --------- ----------------
100.00 0.047467 24 1954 485 total
```
```
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
42.83 0.014521 57 252 unlink
38.41 0.013021 26 486 linkat
18.77 0.006362 25 249 unlinkat
------ ----------- ----------- --------- --------- ----------------
100.00 0.033904 34 987 total
```
This reduces the number of hard-links that are causing perf troubles, noted in https://github.com/rust-lang/rust/issues/64291 and https://github.com/rust-lang/rust/issues/137560
Add an attribute that makes the spans from a macro edition 2021, and fix pin on edition 2024 with it
Fixes a regression, see issue below. This is a temporary fix, super let is the real solution.
Closes#138596
add `naked_functions_target_feature` unstable feature
tracking issue: https://github.com/rust-lang/rust/issues/138568
tagging https://github.com/rust-lang/rust/pull/134213https://github.com/rust-lang/rust/issues/90957
This PR puts `#[target_feature(/* ... */)]` on `#[naked]` functions behind its own feature gate, so that naked functions can be stabilized. It turns out that supporting `target_feature` on naked functions is tricky on some targets, so we're splitting it out to not block stabilization of naked functions themselves. See the tracking issue for more information and workarounds.
Note that at the time of writing, the `target_features` attribute is ignored when generating code for naked functions.
r? ``@Amanieu``
They are marked with hidden visibility to prevent them from getting
exported, so we shouldn't ask the linker to export them anyway. The only
thing that does it cause a warning on macOS.
Computing the current dll path is somewhat expensive relative to other
work when compiling `fn main() {}` as `dladdr` needs to iterate over the
symbol table of librustc_driver.so until it finds a match.
Handle spans of `~const`, `const` and `async` trait bounds in macro expansion
r? `@compiler-errors`
`visit_span` is actually only used in one place (the `transcribe::Marker`), and all of this syntax is unstable, so while it would still be nice to write a test for it, I wager there's lots more interesting things in `transcribe::Marker` to write tests for. And the worst is some diagnostics being weird or incremental being not as incremental as it could be
interpret memory access hooks: also pass through the Pointer used for the access
In some ongoing work on the Miri side, we need the absolute address that the memory access occurred at. That is non-trivial to obtain since we don't have an `ecx`. So pass through the `Pointer` used for the access, which contains the address, and which is available everywhere we are calling these hooks.
r? `@oli-obk`
Rollup of 8 pull requests
Successful merges:
- #138435 (Add support for postfix yield expressions)
- #138685 (Use `Option<Ident>` for lowered param names.)
- #138700 (Suggest `-Whelp` when pass `--print lints` to rustc)
- #138727 (Do not rely on `type_var_origin` in `OrphanCheckErr::NonLocalInputType`)
- #138729 (Clean up `FnCtxt::resolve_coroutine_interiors`)
- #138731 (coverage: Add LLVM plumbing for expansion regions)
- #138732 (Use `def_path_str` for def id arg in `UnsupportedOpInfo`)
- #138735 (Remove `llvm` and `llvms` triagebot ping aliases for `icebreakers-llvm` ping group)
r? `@ghost`
`@rustbot` modify labels: rollup
expand: Leave traces when expanding `cfg_attr` attributes
Currently `cfg_trace` just disappears during expansion, but after this PR `#[cfg_attr(some tokens)]` will leave a `#[cfg_attr_trace(some tokens)]` attribute instead of itself in AST after expansion (the new attribute is built-in and inert, its inner tokens are the same as in the original attribute).
This trace attribute can then be used by lints or other diagnostics, #133823 has some examples.
Tokens in these trace attributes are set to an empty token stream, so the traces are non-existent for proc macros and cannot affect any user-observable behavior.
This is also a weakness, because if a proc macro processes some code with the trace attributes, they will be lost, so the traces are best effort rather than precise.
The next step is to do the same thing with `cfg` attributes (`#[cfg(TRUE)]` currently remains in both AST and tokens after expanding, it should be replaced with a trace instead).
The idea belongs to `@estebank.`
Use `def_path_str` for def id arg in `UnsupportedOpInfo`
We could alternatively just omit the def path from the label, but I think it's fine to keep around
Fixes#138730
coverage: Add LLVM plumbing for expansion regions
This is currently unused, but paves the way for future work on expansion regions without having to worry about the FFI parts.
The span conversion refactoring is only loosely related, but I've included it here because it would conflict with the main changes in `fill_region_tables`, and is pretty straightforward on its own.
Do not rely on `type_var_origin` in `OrphanCheckErr::NonLocalInputType`
The ordering of ty var unification means that we may end up with a root variable whose ty var origin is from another item's params.
Let's not rely on this by just unifying the infer vars with the params of the impl + resolving. It's kinda goofy but it's clearer IMO.
Fixes#132826.
r? `@fmease` or `@lcnr`
Use `Option<Ident>` for lowered param names.
Parameter patterns are lowered to an `Ident` by `lower_fn_params_to_names`, which is used when lowering bare function types, trait methods, and foreign functions. Currently, there are two exceptional cases where the lowered param can become an empty `Ident`.
- If the incoming pattern is an empty `Ident`. This occurs if the parameter is anonymous, e.g. in a bare function type.
- If the incoming pattern is neither an ident nor an underscore. Any such parameter will have triggered a compile error (hence the `span_delayed_bug`), but lowering still occurs.
This commit replaces these empty `Ident` results with `None`, which eliminates a number of `kw::Empty` uses, and makes it impossible to fail to check for these exceptional cases.
Note: the `FIXME` comment in `is_unwrap_or_empty_symbol` is removed. It actually should have been removed in #138482, the precursor to this PR. That PR changed the lowering of wild patterns to `_` symbols instead of empty symbols, which made the mentioned underscore check load-bearing.
r? ``@compiler-errors``
Add support for postfix yield expressions
We've been having a discussion about whether we want postfix yield, or want to stick with prefix yield, or have both. I figured it's easy enough to support both for now and let us play around with them while the feature is still experimental.
This PR treats `yield x` and `x.yield` as semantically equivalent. There was a suggestion to make `yield x` have a `()` type (so it only works in coroutines with `Resume = ()`. I think that'd be worth trying, either in a later PR, or before this one merges, depending on people's opinions.
#43122
Consider fields to be inhabited if they are unstable
Fixes#133885 with a simple heuristic
r? Nadrieril
Not totally certain if this needs T-lang approval or a crater run.
For expansion region support, we will want to be able to convert and check
spans before creating a corresponding local file ID.
If we create local file IDs eagerly, but some expansion turns out to have no
successfully-converted spans, LLVM will complain about that expansion's file ID
having no regions.
It's very useful. There are some false positives involving integration
tests in `rustc_pattern_analysis` and `rustc_serialize`. There is also a
false positive involving `rustc_driver_impl`'s
`rustc_randomized_layouts` feature. And I removed a `rustc_span` mention
in a doc comment in `rustc_log` because it wasn't integral to the
comment but caused a dev-dependency.
Rollup of 7 pull requests
Successful merges:
- #135394 (`MaybeUninit` inherent slice methods part 2)
- #137051 (Implement default methods for `io::Empty` and `io::Sink`)
- #138001 (mir_build: consider privacy when checking for irrefutable patterns)
- #138540 (core/slice: Mark some `split_off` variants unstably const)
- #138589 (If a label is placed on the block of a loop instead of the header, suggest moving it to the header.)
- #138594 (Fix next solver handling of shallow trait impl check)
- #138613 (Remove E0773 "A builtin-macro was defined more than once.")
Failed merges:
- #138602 (Slim `rustc_parse_format` dependencies down)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove E0773 "A builtin-macro was defined more than once."
Error E0773 "A builtin-macro was defined more than once" is triggered when using the same `#[rustc_builtin_macro(..)]` twice. However, it can only be triggered in unstable code (using a `rustc_` attribute), and there doesn't seem to be any harm in using the same implementation from `compiler/rustc_builtin_macros/…` for multiple macro definitions.
By changing the Box to an Arc in `SyntaxExtensionKind`, we can throw away the `BuiltinMacroState::{NotYetSeen, AlreadySeen}` logic, simplifying things.
Fix next solver handling of shallow trait impl check
I'm trying to remove unnecessary direct calls to `select`, and this one seemed like a good place to start 😆
r? `@compiler-errors` or `@lcnr`
If a label is placed on the block of a loop instead of the header, suggest moving it to the header.
Fixes#138585
If a label is placed on the block of a loop instead of the header, suggest to the user moving it to the loop header instead of ~~suggesting to remove it~~ emitting a tool-only suggestion to remove it.
```rs
fn main() {
loop 'a: { return; }
}
```
```diff
error: block label not supported here
--> src/main.rs:2:10
|
2 | loop 'a: { return; }
| ^^^ not supported here
+ |
+help: if you meant to label the loop, move this label before the loop
+ |
+2 - loop 'a: { return; }
+2 + 'a: loop { return; }
+ |
```
Questions for reviewer:
* The "desired output" in the linked issue had the main diagnostic be "misplaced loop label". Should the main diagnostic message the changed instead of leaving it as "block label not supported here"?
* Should this be `Applicability::MachineApplicable`?
mir_build: consider privacy when checking for irrefutable patterns
This PR fixes#137999.
Note that, since this makes the compiler reject code that was previously accepted, it will probably need a crater run.
I include a commit that factors out a common code pattern into a helper function, purely because the fact that this was repeated all over the place was bothering me. Let me know if I should split that into a separate PR instead.
Represent diagnostic side effects as dep nodes
This changes diagnostic to be tracked as a special dep node (`SideEffect`) instead of having a list of side effects associated with each dep node. `SideEffect` is always red and when forced, it emits the diagnostic and marks itself green. Each emitted diagnostic generates a new `SideEffect` with an unique dep node index.
Some implications of this:
- Diagnostic may now be emitted more than once as they can be emitted once when the `SideEffect` gets marked green and again if the task it depends on needs to be re-executed due to another node being red. It relies on deduplicating of diagnostics to avoid that.
- Anon tasks which emits diagnostics will no longer *incorrectly* be merged with other anon tasks.
- Reusing a CGU will now emit diagnostics from the task generating it.
Parameter patterns are lowered to an `Ident` by
`lower_fn_params_to_names`, which is used when lowering bare function
types, trait methods, and foreign functions. Currently, there are two
exceptional cases where the lowered param can become an empty `Ident`.
- If the incoming pattern is an empty `Ident`. This occurs if the
parameter is anonymous, e.g. in a bare function type.
- If the incoming pattern is neither an ident nor an underscore. Any
such parameter will have triggered a compile error (hence the
`span_delayed_bug`), but lowering still occurs.
This commit replaces these empty `Ident` results with `None`, which
eliminates a number of `kw::Empty` uses, and makes it impossible to fail
to check for these exceptional cases.
Note: the `FIXME` comment in `is_unwrap_or_empty_symbol` is removed. It
actually should have been removed in #138482, the precursor to this PR.
That PR changed the lowering of wild patterns to `_` symbols instead of
empty symbols, which made the mentioned underscore check load-bearing.
Remove existing AFIDT implementation
This experiment will need to be reworked differently; I don't think we'll be going with the `dyn* Future` approach that is currently implemented.
r? oli-obk
Fixes#136286Fixes#137706Fixes#137895
Tracking:
* #133119
Revert: Add *_value methods to proc_macro lib
This reverts https://github.com/rust-lang/rust/pull/136355. That PR caused unexpected breakage:
- the rustc-dev component can no longer be loaded by cargo, which impacts Miri and clippy and likely others
- rustc_lexer can no longer be published to crates.io, which impacts RA
See https://github.com/rust-lang/rust/issues/138647 for context.
Cc `@GuillaumeGomez` `@Amanieu`
rust-lang/rust@23032f31c9 accidentally introduced some nondeterminism
in the ordering of lib.rmeta files, which we caught in our bazel-based
builds only recently due to being further behind than normal. In my
testing, this fixes the issue.
