This commit fixes an accidental regression from 144678 where wasm
targets would now accidentally use the wrong import module map for a
symbol causing a symbol to skip mangling. This can result in compilation
failures when symbols are used in cross-crate situations.
Closes 148347
(cherry picked from commit 93fef455de)
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
test(frontmatter): Cover spaces between infostring parts
As these characters are specifically called out in the RFC, I felt it would be important to have a test to cover them.
Tracking issue: rust-lang/rust#136889
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.
[rustdoc] Check `doc(cfg())` even of private/hidden items
Fixes regression found out by `@fmease` [here](https://github.com/rust-lang/rust/pull/138907#discussion_r2382597615).
In short: the pass which checks the `doc(cfg())` attributes needed to be moved before the private/hidden stripping items passes.
Fix invalid jump to def link generated on derive attributes
Fixes https://github.com/rust-lang/rust/issues/147820.
The issue was that we only handled bang macros whereas we should handle all of them.
r? `@notriddle`
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.
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`
Add `FromIterator` impls for `ascii::Char`s to `String`s
Wanted to `collect` ascii chars into a `String` while working on #141369 , and was surprised these impls don't exist. Seems to me to be simply oversight.
BTW, I only added `impl FromIterator<ascii::Char> for Cow<'_, str>`, without a corresponding `FromIterator<&Char>` impl, because there's no existing impl for `FromIterator<&char>`, but that might be oversight too.
cc #110998
`-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.
compiletest: Don't set `TARGET` for non run-make tests
There are a few tests that were using `TARGET` to quietly do nothing on `i586` targets, but it's cleaner to just add support for `//@ ignore-i586` instead.
This lets us get rid of an unsafe `env::set_var` in compiletest, which really should have been setting the environment variable on individual build/run subprocess commands anyway.
- The original code and tests were introduced way back in rust-lang/rust#39068
Add a test for the cold attribute
This adds a test for the cold attribute to verify that it actually does something, and that it applies correctly in all the positions it is expected to work.
There are a few tests that were trying to skip i586 targets via the `TARGET`
environment variable instead, so better to just add support for the directive.
