This used to be necessary for a correct linker order, but ever since the
introduction of symbols.o adding the symbols in question to symbols.o
would work just as well. We do still add dependencies on the panic runtime
to the local crate, but not for #![needs_panic_runtime] crates.
This also removes the runtime-depends-on-needs-runtime test.
inject_dependency_if used to emit this error, but with symbols.o it is
no longer important that there is no dependency and in fact it may be
nice to have panic_abort and panic_unwind directly depend on libstd in
the future for calling std::process::abort().
[RTE-497] Ignore `c-link-to-rust-va-list-fn` test on SGX platform
rust-lang/rust#141856 enables using the runner defined in bootstrap.toml to execute run-make tests. A test was added for this feature that compiles a Rust library and C code, links them together and passes the result to the runner. Unfortunately, that's not sufficient for the SGX platform; x86 machine code cannot be directly executed. This PR fixes the issue by disabling this test for SGX.
Don't include current rustc version string in feature removed help
The version string is difficult to properly normalize out, and removing it isn't a huge deal (the user can query version info easily through `rustc --version` or `cargo --version`).
The normalization options were all non-ideal (see https://github.com/rust-lang/rust/pull/142940#issuecomment-2998518450):
- Per-test version string normalization is nasty to maintain, and we need to maintain `n` copies of it. See rust-lang/rust#142930 where the regex wasn't robust against different release channels.
- Centralized compiletest normalization (with a directive opt-out) is also not ideal, because `cfg(version(..))` tests can't have those accidentally normalized out (and you'd have to remember to opt-out).
r? `@workingjubilee` (discussed in rust-lang/rust#142940)
Emit a single error when importing a path with `_`
When encountering `use _;`, `use _::*'` or similar, do not emit two errors for that single mistake. This also side-steps the issue of resolve errors suggesting adding a crate named `_` to `Cargo.toml`.
Fixrust-lang/rust#142662.
mbe: Clean up code with non-optional `NonterminalKind`
Since [rust-lang/rust#128425], the fragment specifier is unconditionally required in all
editions. This means `NonTerminalKind` no longer needs to be optional,
as we can reject this code during the expansion of `macro_rules!` rather
than handling it throughout the code. Do this cleanup here.
[rust-lang/rust#128425]: https://github.com/rust-lang/rust/pull/128425
Also emit suggestions for usages in the `non_upper_case_globals` lint
This PR adds suggestions for all the usages of the renamed item in the warning of the `non_upper_case_globals` lint.
Fixes https://github.com/rust-lang/rust/issues/124061
```
error[E0382]: borrow of moved value: `x`
--> $DIR/moves-based-on-type-capture-clause-bad.rs:9:20
|
LL | let x = "Hello world!".to_string();
| - move occurs because `x` has type `String`, which does not implement the `Copy` trait
LL | thread::spawn(move || {
| ------- value moved into closure here
LL | println!("{}", x);
| - variable moved due to use in closure
LL | });
LL | println!("{}", x);
| ^ value borrowed here after move
|
= note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider cloning the value before moving it into the closure
|
LL ~ let value = x.clone();
LL ~ thread::spawn(move || {
LL ~ println!("{}", value);
|
```
When encountering `use _;`, `use _::*'` or similar, do not emit two errors for that single mistake. This also side-steps the issue of resolve errors suggesting adding a crate named `_` to `Cargo.toml`.
The version string is difficult to properly normalize out, and removing
it isn't a huge deal (the user can query version info easily through
`rustc --version` or `cargo --version`).
The normalization options were all non-ideal:
- Per-test version string normalization is nasty to maintain, and we
need to maintain `n` copies of it.
- Centralized compiletest normalization (with a directive opt-out) is
also not ideal, because `cfg(version(..))` tests can't have those
accidentally normalized out (and you'd have to remember to opt-out).
Enable reproducible-build-2 for Windows MSVC
Works with MSVC if instructing the linker to avoid timestamps and deleting the PDB between compilations.
Addresses item in rust-lang/rust#128602
---
try-job: x86_64-mingw-*
try-job: x86_64-msvc-*
try-job: i686-msvc-*
[win][aarch64] Fix linking statics on Arm64EC, take 2
Arm64EC builds recently started to fail due to the linker not finding a symbol:
```
symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol)
C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals
```
It turns out that `EMPTY_PANIC` is a new static variable that was being exported then imported from the standard library, but when exporting LLVM didn't prepend the name with `#` (as only functions are prefixed with this character), whereas Rust was prefixing with `#` when attempting to import it.
The fix is to have Rust not prefix statics with `#` when importing.
Adding tests discovered another issue: we need to correctly mark static exported from dylibs with `DATA`, otherwise MSVC's linker assumes they are functions and complains that there is no exit thunk for them.
Fixesrust-lang/rust#138541
Resurrects rust-lang/rust#140176 now that rust-lang/rust#141061 is merged, which removes the incompatibility with `__rust_no_alloc_shim_is_unstable`.
r? ``@wesleywiser``
CC ``@bjorn3``
Remove the deprecated unstable `concat_idents!` macro
In [rust-lang/rust#137653], the lang and libs-API teams did a joint FCP to deprecate
and eventually remove the long-unstable `concat_idents!` macro. The
deprecation is landing in 1.88, so do the removal here (target version
1.90).
This macro has been superseded by the more recent `${concat(...)}`
metavariable expression language feature, which avoids some of the
limitations of `concat_idents!`. The metavar expression is unstably
available under the [`macro_metavar_expr_concat`] feature.
History is mildly interesting here: `concat_idents!` goes back to 2011
when it was introduced with 513276e595 ("Add #concat_idents[] and
#ident_to_str[]"). The syntax looks a bit different but it still works
about the same:
let asdf_fdsa = "<.<";
assert(#concat_idents[asd,f_f,dsa] == "<.<");
assert(#ident_to_str[use_mention_distinction]
== "use_mention_distinction");
(That test existed from introduction until its removal here.)
Closes: https://github.com/rust-lang/rust/issues/29599
[rust-lang/rust#137653]: https://github.com/rust-lang/rust/pull/137653
[`macro_metavar_expr_concat`]: https://github.com/rust-lang/rust/issues/124225
In [137653], the lang and libs-API teams did a joint FCP to deprecate
and eventually remove the long-unstable `concat_idents!` macro. The
deprecation is landing in 1.88, so do the removal here (target version
1.90).
This macro has been superseded by the more recent `${concat(...)}`
metavariable expression language feature, which avoids some of the
limitations of `concat_idents!`. The metavar expression is unstably
available under the [`macro_metavar_expr_concat`] feature.
History is mildly interesting here: `concat_idents!` goes back to 2011
when it was introduced with 513276e595 ("Add #concat_idents[] and
about the same:
let asdf_fdsa = "<.<";
assert(#concat_idents[asd,f_f,dsa] == "<.<");
assert(#ident_to_str[use_mention_distinction]
== "use_mention_distinction");
(That test existed from introduction until its removal here.)
Closes: https://www.github.com/rust-lang/rust/issues/29599
[137653]: https://www.github.com/rust-lang/rust/pull/137653
[`macro_metavar_expr_concat`]: https://www.github.com/rust-lang/rust/issues/124225
`concat_idents!` is in the process of being removed, but a few things it
is used to test will still be relevant. Migrate these tests to something
other than `concat_idents`.
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#140005 (Set MSG_NOSIGNAL for UnixStream)
- rust-lang/rust#140622 (compiletest: Improve diagnostics for line annotation mismatches)
- rust-lang/rust#142354 (Fixes firefox copy paste issue)
- rust-lang/rust#142695 (Port `#[rustc_skip_during_method_dispatch]` to the new attribute system)
- rust-lang/rust#142779 (Add note about `str::split` handling of no matches.)
- rust-lang/rust#142894 (phantom_variance_markers: fix identifier usage in macro)
- rust-lang/rust#142928 (Fix hang in --print=file-names in bootstrap)
- rust-lang/rust#142932 (rustdoc-json: Keep empty generic args if parenthesized)
- rust-lang/rust#142933 (Simplify root goal API of solver a bit)
r? `@ghost`
`@rustbot` modify labels: rollup
compiletest: Improve diagnostics for line annotation mismatches
When some line annotations are missing or misplaced, compiletest reports an error, but the error is not very convenient.
This PR attempts to improve the user experience.
- The "expected ... not found" messages are no longer duplicated.
- The `proc_res.status` and `proc_res.cmdline` message is no longer put in the middle of other messages describing the annotation mismatches, it's now put into the end.
- Compiletest now makes suggestions if there are fuzzy matches between expected and actually reported errors (e.g. the annotation is put on a wrong line).
- Missing diagnostic kinds are no longer produce an error eagerly, but instead treated as always mismatching kinds, so they can produce suggestions telling the right kind.
I'll post screenshots in the thread below, but the behavior shown on the screenshots can be reproduced locally using the new test `tests/ui/compiletest-self-test/line-annotation-mismatches.rs`.
This also fixes https://github.com/rust-lang/rust/issues/140940.
r? ``@jieyouxu``
While cg_llvm is very lax about mismatched function signatures, cg_clif
will crash when there is any mismatch. It could be turned into an error,
but without Cranelift changes can't just be ignored.
Since [1], the fragment specifier is unconditionally required in all
editions. This means `NonTerminalKind` no longer needs to be optional,
as we can reject this code during the expansion of `macro_rules!` rather
than handling it throughout the code. Do this cleanup here.
[1]: https://github.com/rust-lang/rust/pull/128425
Account for beta revisions when normalizing versions
Several UI tests have a `normalize-stderr` for "you are using x.y.z"
rustc versions, and that regex is flexible enough for suffixes like
"-nightly" and "-dev", but not for "-beta.N". We can just add '.' to
that trailing pattern to include this.
To make it match `-Zmacro-stats`, and work better if you have enabled it
for multiple crates.
- Print each crate's name.
- Print a `===` banner at the start and end for separation.
Currently they have the largest items at the end. I believe the
rationale is that it saves you scrolling up through terminal output
because the important stuff is at the bottom. But it's also surprising
and a bit confusing, and I think the obvious order (big things at the
top) is better.
It currently reports net size, i.e. size(output) - size(input). After
some use I think this is sub-optimal, and it's better to just report
size(output). Because for derive macros the input size is always 1, and
for attribute macros it's almost always 1.
Because in the case of for example
pub fn my_fn3(f: impl FnMut()) {}
we want to keep `()` even if it is empty since that matches e.g. Rust
syntax requirements.
Several UI tests have a `normalize-stderr` for "you are using x.y.z"
rustc versions, and that regex is flexible enough for suffixes like
"-nightly" and "-dev", but not for "-beta.N". We can just add '.' to
that trailing pattern to include this.
fix `-Zmin-function-alignment` on functions without attributes
tracking issue: https://github.com/rust-lang/rust/issues/82232
related: https://github.com/rust-lang/rust/pull/142854
The minimum function alignment was skipped on functions without attributes (because the logic was in a loop that only runs if there is at least one attribute). The underlying reason we didn't catch this before is that in our testing we generally apply `#[no_mangle]` to functions that are tested. I've added a test now that deliberately has no attributes.
r? `@workingjubilee`
