Mark desugared range expression spans with DesugaringKind::RangeExpr
This is a prerequisite to removing `QPath::LangItem` (rust-lang/rust#115178) because otherwise there would be no way to detect a range expression in the HIR.
There are some non-obvious Clippy changes so a Clippy team review would be good.
Deduce captures(none) for a return place and parameters
Extend attribute deduction to determine whether parameters using
indirect pass mode might have their address captured. Similarly to
the deduction of `readonly` attribute this information facilitates
memcpy optimizations.
Improve the ICE message for invalid nullary intrinsic calls
In https://github.com/rust-lang/rust/issues/148104, we found the panic message here rather confusing, and (if I'm reading the tea leaves right) that's because the intended audience for either side of the phrase is very different. I think this is more clear if/when this is encountered by users.
I expect this ICE to be hit in practice by people calling the `size_of` and `align_of` intrinsics, so it's now _kind of_ helpful for those users too.
The original effort to stop backends from needing to support nullary intrinsics added a note to all these const-only intrinsics, but when https://github.com/rust-lang/rust/pull/147793 ported two more the paragraph wasn't added. I've added it.
Extend attribute deduction to determine whether parameters using
indirect pass mode might have their address captured. Similarly to
the deduction of `readonly` attribute this information facilitates
memcpy optimizations.
StateTransform: Only load pin field once.
The current implementation starts by transforming all instances of `_1` into `(*_1)`, and then traverses the body again to transform `(*_1)` into `(*(_1.0))`, and again for `Derefer`.
This PR changes the implementation to only traverse the body once. As `_1.0` cannot be not modified inside the body (we just changed its type!), we have no risk of loading from the wrong pointer.
chore: Update to the latest annotate-snippets
This PR updates `annotate-snippets` to the latest version and updates the adapter code[^1] so that `AnnotateSnippetEmitter`'s output matches `HumanEmitter`'s output. If anyone would like to see the differences[^2] between `AnnotateSnippetEmitter` and `HumanEmitter`, [I have a branch](https://github.com/Muscraft/rust/tree/annotate-snippets-default-renderer) where `AnnotateSnippetEmitter` is used in place of `HumanEmitter`.
[^1]: A lot of the adapter code changes are based on code for `HumanEmitter`.
[^2]: Some of the test differences will go away when rust-lang/rust#148001 and rust-lang/rust#148004 are merged.
Improvements to attribute suggestions
Changes in commit 1:
- Add `AcceptContext::suggestions`, which retrieves the suggestions for the currently parsing attribute
- This happens to fix a bug in the way `#[macro_export`]. Closes https://github.com/rust-lang/rust/pull/147987
Changes in commit 2:
- Add a check to the suggestions function so the suggestions for attributes in cfg_attr are nicer. Fixes https://github.com/rust-lang/rust/issues/147693
This is also part (but not all) of the changes needed to unblock https://github.com/rust-lang/rust/pull/147945
r? `@jdonszelmann`
Stop passing resolver disambiguator state to AST lowering.
AST->HIR lowering can use a disjoint set of `DefPathData` as the resolver, so we don't need to pass the disambiguator state.
r? `@oli-obk`
hir_analysis: add missing sizedness bounds
Depends on rust-lang/rust#144064
Default sizedness bounds were not being added to `explicit_super_predicates_of` and `explicit_implied_predicates_of` which meant that a trait bound added to a associated type projection would be missing the implied predicate of the default sizedness supertrait of that trait.
An unexpected consequence of this change was that the check for multiple principals was now finding an additional `MetaSized` principal when eagerly expanding trait aliases - which is fixed by skipping `MetaSized` when elaborating trait aliases in lowering `dyn TraitAlias`.
fix panic when rustc tries to reduce intermediate filenames len with utf8
The issue cannot be reproduced with the former testcase of creating external crates because rust refuses to use "external crate 28_找出字符串中第一个匹配项的下标" because it is not a valid indentifier (starts with number, and contain non ascii chars)
But still using 28_找出字符串中第一个匹配项的下标.rs as a filename is accepted by previous rustc releases So we consider it valid, and add an integration test for it to catch any regression on other code related to non ascii filenames.
Fixrust-lang/rust#147975
Default sizedness bounds were not being added to
`explicit_super_predicates_of` and `explicit_implied_predicates_of`
which meant that a trait bound added to a associated type projection
would be missing the implied predicate of the default sizedness
supertrait of that trait.
An unexpected consequence of this change was that the check for multiple
principals was now finding an additional `MetaSized` principal when
eagerly expanding trait aliases. Instead of special-casing trait aliases
as different from traits and not adding a `MetaSized` supertrait to trait
aliases, filter out `MetaSized` when lowering `dyn Trait`.
The issue cannot be reproduced with the former testcase of creating external crates because
rust refuses to use "external crate 28_找出字符串中第一个匹配项的下标"
because it is not a valid indentifier (starts with number, and contain non ascii chars)
But still using 28_找出字符串中第一个匹配项的下标.rs as a filename is accepted by previous rustc releases
So we consider it valid, and add an integration test for it to catch any regression on other code related to non ascii filenames.
rustc_codegen_llvm: adapt for LLVM 22 change to pass masked intrinsic alignment as an attribute
This was a bit more invasive than I had kind of hoped. An alternate approach would be to add an extra call_intrinsic_with_attrs() that would have the new-in-this-change signature for call_intrinsic, but this felt about equivalent and made it a little easier to audit the relevant callsites of call_intrinsic().
Related LLVM change is llvm/llvm-project#163802.
`@rustbot` label llvm-main
Streamline iterator chaining when computing successors.
There are numerous unnecessary `into_iter` calls.
Also add a comment explaining why the code looks like this, because it's non-obvious at first glance.
r? `@saethlin`
There are numerous unnecessary `into_iter` calls.
Also add a comment explaining why the code looks like this, because it's
non-obvious at first glance.
This was a bit more invasive than I had kind of hoped. An alternate
approach would be to add an extra call_intrinsic_with_attrs() that would
have the new-in-this-change signature for call_intrinsic, but this felt
about equivalent and made it a little easier to audit the relevant
callsites of call_intrinsic().
fix: Don't add diff symbol to unchanged lines
When rendering a "multi-line" suggestion with the [`Diff`](dc1feabef2/compiler/rustc_errors/src/emitter.rs (L3078)) format, `rustc` uses a [diff symbol](dc1feabef2/compiler/rustc_errors/src/emitter.rs (L3017-L3022)) for
[any line that has a highlight part](dc1feabef2/compiler/rustc_errors/src/emitter.rs (L2705-L2713)). This includes highlight parts that are highlighting nothing, i.e., a span of `0..0`. This leads `rustc` to add a diff symbol unnecessarily to lines that have no changes and are not highlighted. This PR makes it so that `rustc` will not add a diff symbol to lines that contain no changes/highlights.
Note: This PR is part of my ongoing effort to have `rustc` use `annotate-snippets` for rendering. This change will make it so that `rustc` and `annotate-snippets` will match in this case.
feat(rustdoc): `--emit=depinfo` output to stdout via `-`
rustdoc's `--emit=depinfo` flag now supports using `-` to write the output to stdout,
aligning with rustc's behavior.
This will fix <https://github.com/rust-lang/rust/issues/147649>.
### How to review
* The first commit demonstrates that `rustdoc --emit=depinfo=-` hasn't yet supported emitting to stdout.
* The second implements it and the diff shows how the behavior changes.
Reword unstable fingerprints ICE to ask for reproduction
When the unstable fingerprints error was added, Rust was on fire, and we needed a quick way for people to sort of understand what's going on, follow the tracking issue, and leave some information without overwhelming the issue tracker and focusing on getting their code working.
This is what motivated the previous message. It called this a "known issue", provided help on how to fix it, and only secondarily asked for a bug report.
This is no longer true. These days incremental compilation is fairly solid and these issues are supposed to be rare, we expect *none* of them to exist (but obviously know that's not true). As such, it's time to reword this message.
Recently someone mentioned how they didn't bother reporting this issue because it said that it was a "known issue", and I only got awareness of their problem because they complained about all the rustc-ice files hanging around their directories (https://github.com/rust-lang/rust/issues/147825#issuecomment-3417297842). This is not at all what we want, we want reports from people, ideally with a reproduction.
To get this, I reworded the error. It now explicitly asks for a reproduction (and explaining what that means) and no longer calls it a "known issue". It also does not link to the tracking issue anymore, because I don't think this tracking issue is useful. It should probably be closed.
I still mention the workaround, but explicitly call it a "workaround". People should report a reproduction and only *then* use the workaround.
refactor: Move to anstream + anstyle for styling
`rustc` uses [`termcolor`](https://crates.io/crates/termcolor) for styling and writing, while `annotate-snippets` uses [`anstyle`](https://crates.io/crates/anstyle) for styling and currently writes directly to a `String`. When rendering directly to a terminal, there isn't/shouldn't be any differences. Still, there are differences in the escape sequences, which leads to slightly different output in JSON and SVG tests. As part of my work to have `rustc` use `annotate-snippets`, and to reduce the test differences between the two, I switched `rustc` to use `anstlye` and [`anstream`](https://crates.io/crates/anstream) for styling and writing.
The first commit migrates to `anstyle` and `anstream` and notably does not change the output. This is because it includes extra formatting to ensure that `anstyle` + `anstream` match the current output exactly. Most of this code is unnecessary, as it adds redundant resets or uses 256-color (8-bit) when it could be using 4-bit color. The subsequent commits remove this extra formatting while maintaining the correct output when rendered.
[Zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/147480-t-compiler.2Fdiagnostics/topic/annotate-snippets.20hurdles)
Forbid ShallowInitBox after box deref elaboration.
MIR currently contains a `ShallowInitBox` rvalue. Its principal usage is to allow for in-place initialization of boxes. Having it is necessary for drop elaboration to be correct with that in-place initialization.
As part of analysis->runtime MIR lowering, we canonicalize deref of boxes to use the stored raw pointer. But we did not perform the same change to the construction of the box.
This PR replaces `ShallowInitBox` by the pointer manipulation it represents.
Alternatives:
- fully remove `ShallowInitBox` and implement `Box` in-place initialization differently;
- remove the `ElaborateBoxDeref` pass and keep dereferencing `Box` in runtime MIR.
