Rollup of 8 pull requests
Successful merges:
- #83433 (Pass --cfg=bootstrap for proc macros built by stage0)
- #84940 (Don't run sanity checks for `x.py setup`)
- #85912 (Use `Iterator::any` and `filter_map` instead of open-coding them)
- #85965 (Remove dead code from `LocalAnalyzer`)
- #86010 (Fix two ICEs in the parser)
- #86040 (Fix display for search results)
- #86058 (Remove `_` from E0121 diagnostic suggestions)
- #86077 (Fix corrected example in E0759.md)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
This patch fixes tests from failing that were matching on `Box<Any>`,
which was the old panic message. Since the new panic message is `Box<dyn
Any>`, the tests have been updated to match against this instead.
Fix corrected example in E0759.md
This pull request fixes#86061, which was probably caused by a copy-paste error, where the supposedly corrected code example was also marked with `compile_fail`. Thus, the fact that the "correct" example actually _isn't_ correct was not caught by the doc-tests. This pull request removes the incorrect `compile_fail` annotation and fixes the example.
r? ``@GuillaumeGomez``
Fix two ICEs in the parser
This pull request fixes#84104 and fixes#84148. The latter is caused by an invalid `assert_ne!()` in the parser, which I have simply removed because the error is then caught in another part of the parser.
#84104 is somewhat more subtle and has to do with a suggestion to remove extraneous `<` characters; for instance:
```rust
fn main() {
foo::<Ty<<<i32>();
}
```
currently leads to
```
error: unmatched angle brackets
--> unmatched-langle.rs:2:10
|
2 | foo::<Ty<<<i32>();
| ^^^ help: remove extra angle brackets
```
which is obviously wrong and stems from the fact that the code for issuing the above suggestion does not consider the possibility that there might be other tokens in between the opening angle brackets. In #84104, this has led to a span being generated that ends in the middle of a multi-byte character (because the code issuing the suggestion thought that it was only skipping over `<`, which are single-byte), causing an ICE.
Don't run sanity checks for `x.py setup`
These requirements change as soon as the command finishes running, and
`setup` doesn't build anything, so the check doesn't make sense.
Previously, `x.py setup` would give hard errors if `ninja` and `cmake`
were not installed, even if the new profile didn't require them.
Fixes https://github.com/rust-lang/rust/issues/84938.
Pass --cfg=bootstrap for proc macros built by stage0
Cargo has a bug where it ignores RUSTFLAGS when building proc macro
crates (https://github.com/rust-lang/cargo/issues/4423).
However, sometimes rustc_macro needs to have conditional
compilation when there are breaking changes to the `libproc_macro` API
(see for example #83363). Previously, this wasn't possible, because the
crate couldn't tell the difference between stage 0 and stage 1.
Another alternative is to unconditionally build rustc_macros with the
master libstd instead of the beta one (i.e. use `--sysroot
stage0-sysroot`), but that led to strange and maddening errors:
```
error[E0460]: found possibly newer version of crate `std` which `synstructure` depends on
--> compiler/rustc_macros/src/lib.rs:5:5
|
5 | use synstructure::decl_derive;
| ^^^^^^^^^^^^
|
= note: perhaps that crate needs to be recompiled?
= note: the following crate versions were found:
crate `std`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-b3602c301b71cc3d.rmeta
crate `synstructure`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps/libsynstructure-74ee66863479e972.rmeta
error[E0460]: found possibly newer version of crate `std` which `proc_macro2` depends on
--> /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/tracing-attributes-0.1.13/src/lib.rs:90:5
|
90 | use proc_macro2::TokenStream;
| ^^^^^^^^^^^
|
= note: perhaps that crate needs to be recompiled?
= note: the following crate versions were found:
crate `std`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-sysroot/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-b3602c301b71cc3d.rmeta
crate `proc_macro2`: /home/joshua/rustc2/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps/libproc_macro2-a83c1f01610c129e.rlib
```
r? `@Mark-Simulacrum` cc `@jhpratt`
Prior to this patch, the default panic message (resulting from calling
`panic_any(42);` for example), would print the following error message:
```
thread 'main' panicked at 'Box<Any>', ...
```
However, this should be `Box<dyn Any>` instead.
Add variance-related information to lifetime error messages
This PR adds a basic framework for displaying variance-related information in error messages. For example:
```
error: lifetime may not live long enough
--> $DIR/type-check-pointer-comparisons.rs:12:5
|
LL | fn compare_mut<'a, 'b>(x: *mut &'a i32, y: *mut &'b i32) {
| -- -- lifetime `'b` defined here
| |
| lifetime `'a` defined here
LL | x == y;
| ^ requires that `'a` must outlive `'b`
|
= help: consider adding the following bound: `'a: 'b`
= note: requirement occurs because of a mutable pointer to &i32
= note: mutable pointers are invariant over their type parameter
= help: see <https://doc.rust-lang.org/nomicon/subtyping.html> for more information about variance
```
The last three lines are new.
This is accomplished by adding a new struct `VarianceDiagInfo`, and passing it along through the various relation methods. When relating types that change the variance (e.g. `&mut T` or `*mut T`), we pass a more specific `VarianceDiagInfo` storing information about the cause of the variance change. When an error, we use the `VarianceDiagInfo` to add additional information to the error message.
This PR doesn't change any variance-related computation or behavior - only diagnostic messages. Therefore, the implementation is quite incomplete - more detailed error messages can be filled in in subsequent PRs.
Limitations:
* We only attempt to deal with invariance - since it's at the bottom of the 'variance lattice', our variance will never change again after it becomes invariant. Handling contravariance would be trickier, since we can change between contravariance and covariance multiple times (e.g. `fn(fn(&'static u8))`). Since contravariance (AFAIK) is only used for function arguments, we can probably get away without a very fancy message for cases involving contravariance.
* `VarianceDiagInfo` currently only handles mutable pointers/references. However, user-defined types (structs, enums, and unions) have the variance of their type parameters inferred, so it would be good to eventually display information about that. We'll want to try to find a balance between displaying too much and too little information about how the variance was inferred.
* The improved error messages are only displayed when `#![feature(nll)]` / `-Z borrowck=mir` is enabled. If issue https://github.com/rust-lang/rust/issues/58781 is not resolved relatively soon, then we might want to duplicate some of this logic in the 'current' (non-NLL) region/outlives handling code.
linker: Reorder linker arguments
- Split arguments into order-independent and order-dependent, to define more precisely what (pre-,post-,late-,)link-args mean.
- Add some comments.
- Combine all native library arguments together, to simplify potential support for library deduplication and similar things
- Split arguments into order-independent and order-dependent, to define more precisely what (pre,post,late)-link-args mean
parser: Ensure that all nonterminals have tokens after parsing
`parse_nonterminal` should always result in something with tokens.
This requirement wasn't satisfied in two cases:
- `stmt` nonterminal with expression statements (e.g. `0`, or `{}`, or `path + 1`) because `fn parse_stmt_without_recovery` forgot to propagate `force_collect` in some cases.
- `expr` nonterminal with expressions with built-in attributes (e.g. `#[allow(warnings)] 0`) due to an incorrect optimization in `fn parse_expr_force_collect`, it assumed that all expressions starting with `#` have their tokens collected during parsing, but that's not true if all the attributes on that expression are built-in and inert.
(Discovered when trying to implement eager `cfg` expansion for all attributes https://github.com/rust-lang/rust/pull/83824#issuecomment-817317170.)
r? `@Aaron1011`
Drop an `if let` that will always succeed
We've already checked that `proj_base == []` in the line above and renaming
`place_local` to `local` doesn't gain us anything.
``@rustbot`` modify labels +C-cleanup +T-compiler
Rustdoc html fixes
#84480 latest update allowed me to fix the remaining issues. The last one is coming from `pulldown-cmark` so I'll send them a fix soon.
r? ``@jsha``
Update standard library for IntoIterator implementation of arrays
This PR partially resolves issue #84513 of updating the standard library part.
I haven't found any remaining doctest examples which are using iterators over e.g. &i32 instead of just i32 in the standard library. Can anyone point me to them if there's remaining any?
Thanks!
r? ```@m-ou-se```
Tweak wasm_base target spec to indicate linker is not GNU and update linker inferring logic for wasm-ld.
Reported via [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/wasi.20linker.20unknown.20argument.3A.20--as-needed): we try passing `--as-needed` to the linker if it's GNU ld which `wasm-ld` is not. Usually this isn't an issue for wasm as we would use the WasmLd linker driver but because the linker in question (`wasm32-unknown-wasi-wasm-ld`) ended with `-ld` our linker inferring [logic](f64503eb55/compiler/rustc_codegen_ssa/src/back/link.rs (L957-L1040)) used the `GccLinker` implementations. (UPD: The linker inferring logic actually didn't apply in this case because the linker is actually invoked through gcc in the reported issue. But it's still worth updating the logic I think.)
This change then has 2 parts:
1. Update wasm_base target spec to indicate `linker_is_gnu: false` plus a few additions of `target.is_like_wasm` to handle flags `wasm-ld` does in fact support.
2. Improve the linker detection logic to properly determine the correct flavor of wasm linker we're using when we can.
We need to add the new `target.is_like_wasm` branches to handle the case where the "linker" used could be something like clang which would then under the hood call wasm-ld.
Preserve metadata w/ Solaris-like linkers.
#84468 moved the `-zignore` linker flag from the `gc_sections` method to `add_as_needed` which is more accurate but Solaris-style linkers will also end up removing an unreferenced ELF sections [1]. This had the unfortunate side effect of causing the `.rustc` section (which has the metada) to be removed which could cause issues when trying to link against the resulting crates or use proc macros.
Since the `-zignore` is positional, we fix this by moving the metadata objects to before the flag.
[1] Specifically a section is considered unreferenced if:
* The section is allocatable
* No other sections bind to (relocate) to this section
* The section provides no global symbols
https://docs.oracle.com/cd/E19683-01/817-3677/6mj8mbtbs/index.html#chapter4-19
Show test type during prints
Test output can sometimes be confusing. For example doctest with the no_run argument are displayed the same way than test that are run.
During #83857 I got the feedback that test output can be confusing.
For the moment test output is
```
test $DIR/test-type.rs - f (line 12) ... ignored
test $DIR/test-type.rs - f (line 15) ... ok
test $DIR/test-type.rs - f (line 21) ... ok
test $DIR/test-type.rs - f (line 6) ... ok
```
I propose to change output by indicating the test type as
```
test $DIR/test-type.rs - f (line 12) ... ignored
test $DIR/test-type.rs - f (line 15) - compile ... ok
test $DIR/test-type.rs - f (line 21) - compile fail ... ok
test $DIR/test-type.rs - f (line 6) ... ok
```
by indicating the test type after the test name (and in the case of doctest after the function name and line) and before the "...".
------------
Note: this is a proof of concept, the implementation is probably not optimal as the properties added in `TestDesc` are only use in the display and does not represent actual change of behavior, maybe `TestType::DocTest` could have fields
Partial support for raw-dylib linkage
First cut of functionality for issue #58713: add support for `#[link(kind = "raw-dylib")]` on `extern` blocks in lib crates compiled to .rlib files. Does not yet support `#[link_name]` attributes on functions, or the `#[link_ordinal]` attribute, or `#[link(kind = "raw-dylib")]` on `extern` blocks in bin crates; I intend to publish subsequent PRs to fill those gaps. It's also not yet clear whether this works for functions in `extern "stdcall"` blocks; I also intend to investigate that shortly and make any necessary changes as a follow-on PR.
This implementation calls out to an LLVM function to construct the actual `.idata` sections as temporary `.lib` files on disk and then links those into the generated .rlib.
BPF target support
This adds `bpfel-unknown-none` and `bpfeb-unknown-none`, two new no_std targets that generate little and big endian BPF. The approach taken is very similar to the cuda target, where `TargetOptions::obj_is_bitcode` is enabled and code generation is done by the linker.
I added the targets to `dist-various-2`. There are [some tests](https://github.com/alessandrod/bpf-linker/tree/main/tests/assembly) in bpf-linker and I'm planning to add more. Those are currently not ran as part of rust CI.
