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.
PassWrapper: Access GlobalValueSummaryInfo::SummaryList via getter for LLVM 22+
https://github.com/llvm/llvm-project/pull/164355 makes SummaryList private and provides a getter method.
`@rustbot` label llvm-main
Code refactoring on hir report_no_match_method_error
While working on rust-lang/rust#147753, I found `report_no_match_method_error` now is too long for maintain, 1200 lines of code now:
57ef8d642d/compiler/rustc_hir_typeck/src/method/suggest.rs (L589-L1736)
this PR try to refactor it.
I tried my best to group most related code into same places, but the logic here is still very complex, there are some variables across different functions, maybe we need more work to make it better understand.
Maybe we could add a tidy check to avoid long spaghetti code.
r? `@nnethercote`
Add NonNull pattern types
These are the final piece missing for
* https://github.com/rust-lang/rust/pull/136006
We cannot use the previous scheme of using an integer range for raw pointers, as we're not just changing the layout of raw pointers anymore, but also the type representation. And we can't represent "any provenance or NonZero<usize>" natively as patterns. So I created a new `!null` pattern. Since this is all unstable representation stuff for replacing rustc_layout_scalar_range_start with pattern types, the divergence from normal patterns is fine, especially since T-lang seems interested in exploring general negation patterns
r? `@BoxyUwU`
`-Znext-solver` instantiate predicate binder without recanonicalizing goal
This strengthens the leak check to match the old trait solver. The new trait solver now also instantiates higher ranked goals in the same scope as candidate selection, so the leak check in each candidate detects placeholder errors involving this higher ranked goal.
E.g. let's look at tests/ui/higher-ranked/leak-check/leak-check-in-selection-2.rs
```rust
trait Trait<T, U> {}
impl<'a> Trait<&'a str, &'a str> for () {}
impl<'a> Trait<&'a str, String> for () {}
fn impls_trait<T: for<'a> Trait<&'a str, U>, U>() {}
fn main() {
impls_trait::<(), _>();
}
```
Here proving `(): for<'a> Trait<&'a str, ?u>` via `impl<'a> Trait<&'a str, &'a str> for ()` equates `?u` with `&'!a str` which results in a leak check error as `?u` cannot name `'a`. If this leak check error happens while considering candidates we drop the first impl and infer `?u` to `String`. If not, this remains ambiguous.
This behavior is a bit iffy, see the FCP proposal in rust-lang/rust#119820 for more details on why this current behavior is somewhat undesirable. However, considering placeholders from higher-ranked goals for candidate selection does allow more code to compile and a lot of the code *feels like it should compile*. **This caused us to revert the change of rust-lang/rust#119820 in rust-lang/rust#127568.**
I originally expected that we can avoid breakage with the new solver differently here, e.g. by considering OR-region constraints. However, doing so is a significant change and I don't have a great idea for how that should work. Matching the old solver behavior for now should not make this cleaner approach any more difficult in the future, so let's just go with what actually allows us to stabilize the new solver for now.
This PR changing the new solver to match the behavior of the old one wrt the leak check. As the new solver is already used by default in coherence, this allows more code to compile, see `tests/ui/higher-ranked/leak-check/leak-check-in-selection-7-coherence.rs`:
```rust
struct W<T, U>(T, U);
trait Trait<T> {}
// using this impl results in a higher-ranked region error.
impl<'a> Trait<W<&'a str, &'a str>> for () {}
impl<'a> Trait<W<&'a str, String>> for () {}
trait NotString {}
impl NotString for &str {}
impl NotString for u32 {}
trait Overlap<U> {}
impl<T: for<'a> Trait<W<&'a str, U>>, U> Overlap<U> for T {}
impl<U: NotString> Overlap<U> for () {}
fn main() {}
```
This behavior is quite arbitrary and not something I expect users to rely on in practice, however, it should still go through an FCP imo.
r? `@BoxyUwU` originally implemented by `@compiler-errors` in https://github.com/rust-lang/rust/pull/136997. Closes https://github.com/rust-lang/trait-system-refactor-initiative/issues/120.
