Make decoding non-optional `LazyArray` panic if not set
Tables may be [defined](9649706ead/compiler/rustc_metadata/src/rmeta/mod.rs (L377)) as `optional:` or `defaulted:`. If optional, if we try to read a value from a key that was never encoded, we should panic. This has high value in ensuring correctness over a defaulted table, so the tradeoff is worth considering, since it signals the compiler has a buggy encode impl, rather than just defaulting to a value.
HOWEVER, `optional:` arrays were side-stepping this. So this PR fixes that, and makes `optional:` tables of `LazyArray` act like `LazyValue`, and panic if it's not assigned a value during encoding.
During this PR, I found that `deduced_param_attrs` has buggy (?? i think??) implementation where it will refuse to encode cross-crate `deduced_param_attrs` unless we're codegening, we're optimizing the library, and incremental is disabled. This seems incredibly wrong, but I don't want to fix it in this PR.
9649706ead/compiler/rustc_metadata/src/rmeta/encoder.rs (L1733-L1747)
Replace walk with visit so we dont skip outermost expr kind in def collector
This affects async closures with macros as their body expr. Fixes#129855.
r? ``@cjgillot`` or anyone else
Fix LLVM ABI NAME for riscv64imac-unknown-nuttx-elf
This patch fix https://github.com/rust-lang/rust/issues/129825
For the riscv64imac target, the LLVM ABI NAME should be "lp64", which is the default ABI if not specified for the riscv64imac target.
Deny imports of `rustc_type_ir::inherent` outside of type ir + new trait solver
We shouldn't encourage using `rustc_type_ir::inherent` outside of the new solver[^1], though this can happen by accident due to rust-analyzer, for example. See https://github.com/rust-lang/rust/pull/127537#discussion_r1733813842 for an example in practice.
r? fmease
[^1]: Unless we go the fully radical approach of always using these inherent methods everywhere in favor of inherent methods, which would be a major overhaul of the compiler, IMO. I don't really want to consider that possibility right now, tho.
Rewrite lint_expectations in a single pass.
This PR aims at reducing the perf regression from https://github.com/rust-lang/rust/pull/120924#issuecomment-2202486203 with drive-by simplifications.
Basically, instead of using the lint level builder, which is slow, this PR splits `lint_expectations` logic in 2:
- listing the `LintExpectations` is done in `shallow_lint_levels_on`, on a per-owner basis;
- building the unstable->stable expectation id map is done by iterating on attributes.
r? ghost for perf
add `aarch64_unknown_nto_qnx700` target - QNX 7.0 support for aarch64le
This backports the QNX 7.1 aarch64 implementation to 7.0.
* [x] required `-lregex` disabled, see https://github.com/rust-lang/libc/pull/3775 (released in libc 0.2.156)
* [x] uses `libgcc.a` instead of `libgcc_s.so` (7.0 used ancient GCC 5.4 which didn't have gcc_s)
* [x] a fix in `backtrace` crate to support stack traces https://github.com/rust-lang/backtrace-rs/pull/648
This PR bumps libc dependency to 0.2.158
CC: to the folks who did the [initial implementation](https://doc.rust-lang.org/rustc/platform-support/nto-qnx.html): `@flba-eb,` `@gh-tr,` `@jonathanpallant,` `@japaric`
# Compile target
```bash
# Configure qcc build environment
source _path_/_to_/qnx7.0/qnxsdp-env.sh
# Tell rust to use qcc when building QNX 7.0 targets
export build_env='
CC_aarch64-unknown-nto-qnx700=qcc
CFLAGS_aarch64-unknown-nto-qnx700=-Vgcc_ntoaarch64le_cxx
CXX_aarch64-unknown-nto-qnx700=qcc
AR_aarch64_unknown_nto_qnx700=ntoaarch64-ar'
# Build rust compiler, libs, and the remote test server
env $build_env ./x.py build \
--target x86_64-unknown-linux-gnu,aarch64-unknown-nto-qnx700 \
rustc library/core library/alloc library/std src/tools/remote-test-server
rustup toolchain link stage1 build/host/stage1
```
# Compile "hello world"
```bash
source _path_/_to_/qnx7.0/qnxsdp-env.sh
cargo new hello_world
cd hello_world
cargo +stage1 build --release --target aarch64-unknown-nto-qnx700
```
# Configure a remote for testing
Do this from a new shell - we will need to run more commands in the previous one. I ran into these two issues, and found some workarounds.
* Temporary dir might not work properly
* Default `remote-test-server` has issues binding to an address
```
# ./remote-test-server
starting test server
thread 'main' panicked at src/tools/remote-test-server/src/main.rs:175:29:
called `Result::unwrap()` on an `Err` value: Os { code: 249, kind: AddrNotAvailable, message: "Can't assign requested address" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Specifying `--bind` param actually fixes that, and so does setting `TMPDIR` properly.
```bash
# Copy remote-test-server to remote device. You may need to use sftp instead.
# ATTENTION: Note that the path is different from the one in the remote testing documentation for some reason
scp ./build/x86_64-unknown-linux-gnu/stage1-tools-bin/remote-test-server qnxdevice:/path/
# Run ssh with port forwarding - so that rust tester can connect to the local port instead
ssh -L 12345:127.0.0.1:12345 qnxdevice
# on the device, run
rm -rf tmp && mkdir -p tmp && TMPDIR=$PWD/tmp ./remote-test-server --bind 0.0.0.0:12345
```
# Run test suit
Assume all previous environment variables are still set, or re-init them
```bash
export TEST_DEVICE_ADDR="localhost:12345"
# tidy needs to be skipped due to using un-published libc dependency
export exclude_tests='
--exclude src/bootstrap
--exclude src/tools/error_index_generator
--exclude src/tools/linkchecker
--exclude src/tools/tidy
--exclude tests/ui-fulldeps
--exclude rustc
--exclude rustdoc
--exclude tests/run-make-fulldeps'
env $build_env ./x.py test $exclude_tests --stage 1 --target aarch64-unknown-nto-qnx700
```
try-job: dist-x86_64-msvc
This patch fix https://github.com/rust-lang/rust/issues/129825
For the riscv64imac target, the LLVM ABI NAME should be "lp64",
which is the default ABI if not specified for the riscv64imac target.
Update stacker to 0.1.17
The main new feature is support for detecting the current stack size on illumos. (See [my blog post] for the context which led to this.)
[my blog post]: https://sunshowers.io/posts/rustc-segfault-illumos/
try-job: x86_64-mingw
Rollup of 11 pull requests
Successful merges:
- #128523 (Add release notes for 1.81.0)
- #129605 (Add missing `needs-llvm-components` directives for run-make tests that need target-specific codegen)
- #129650 (Clean up `library/profiler_builtins/build.rs`)
- #129651 (skip stage 0 target check if `BOOTSTRAP_SKIP_TARGET_SANITY` is set)
- #129684 (Enable Miri to pass pointers through FFI)
- #129762 (Update the `wasm-component-ld` binary dependency)
- #129782 (couple more crash tests)
- #129816 (tidy: say which feature gate has a stability issue mismatch)
- #129818 (make the const-unstable-in-stable error more clear)
- #129824 (Fix code examples buttons not appearing on click on mobile)
- #129826 (library: Fix typo in `core::mem`)
r? `@ghost`
`@rustbot` modify labels: rollup
make the const-unstable-in-stable error more clear
The default should be to add `rustc_const_unstable`, not `rustc_allow_const_fn_unstable`.
Also I discovered our check for missing const stability attributes on stable functions -- but strangely that check only kicks in for "reachable" functions. `check_missing_stability` checks for reachability since all reachable functions must have a stability attribute, but I would say if a function has `#[stable]` it should also have const-stability attributes regardless of reachability.
Update the `wasm-component-ld` binary dependency
This keeps it up-to-date by moving from 0.5.6 to 0.5.7. While here I've additionally updated some other wasm-related dependencies in the workspace to keep them up-to-date and try to avoid duplicate versions as well.
Enable Miri to pass pointers through FFI
Following https://github.com/rust-lang/rust/pull/126787, the purpose of this PR is to now enable Miri to execute native calls that make use of pointers.
> <details>
>
> <summary> Simple example </summary>
>
> ```rust
> extern "C" {
> fn ptr_printer(ptr: *mut i32);
> }
>
> fn main() {
> let ptr = &mut 42 as *mut i32;
> unsafe {
> ptr_printer(ptr);
> }
> }
> ```
> ```c
> void ptr_printer(int *ptr) {
> printf("printing pointer dereference from C: %d\n", *ptr);
> }
> ```
> should now show `printing pointer dereference from C: 42`.
>
> </details>
Note that this PR does not yet implement any logic involved in updating Miri's "analysis" state (byte initialization, provenance) upon such a native call.
r? ``@RalfJung``
Remove `#[macro_use] extern crate tracing`, round 4
Because explicit importing of macros via use items is nicer (more standard and readable) than implicit importing via #[macro_use]. Continuing the work from #124511, #124914, and #125434. After this PR no `rustc_*` crates use `#[macro_use] extern crate tracing` except for `rustc_codegen_gcc` which is a special case and I will do separately.
r? ```@jieyouxu```
llvm-wrapper: adapt for LLVM API changes
No functional changes intended.
Updates the wrapper for 21eddfac3d.
````@rustbot```` label: +llvm-main
r? ````@nikic````
Expand NLL MIR dumps
This PR is a first step to clean up and expand NLL MIR dumps:
- by restoring the "mir-include-spans" comments which are useful for `-Zdump-mir=nll`
- by adding the list of borrows to NLL MIR dumps, where they are introduced in the CFG and in which region
Comments in MIR dumps were turned off in #112346, but as shown in #114652 they were still useful for us working with NLL MIR dumps. So this PR pulls `-Z mir-include-spans` into its own options struct, so that passes dumping MIR can override them if need be. The rest of the compiler is not affected, only the "nll" pass dumps have these comments enabled again. The CLI still has priority when specifying the flag, so that we can explicitly turn them off in the `mir-opt` tests to keep blessed dumps easier to work with (which was one of the points of #112346).
Then, as part of a couple steps to improve NLL/polonius MIR dumps and `.dot` visualizations, I've also added the list of borrows and where they're introduced. I'm doing all this to help debug some polonius scope issues in my prototype location-sensitive analysis :3. I'll probably add member constraints soon.
const fn stability checking: also check declared language features
Fixes https://github.com/rust-lang/rust/issues/129656
`@oli-obk` I assume it is just an oversight that this didn't use `features().declared()`? Or is there a deep reason that this must only check `declared_lib_features`?
interpret/visitor: make memory order iteration slightly more efficient
Finally I know enough about RPIT to write this iterator signature correctly. :D
This means memory-order iteration now needs an allocation, but it avoids quadratic complexity (where it has to do a linear scan n times to find the n-th field in memory order), so that seems like a win overall. The changed code only affects Miri; the rustc changes are NOPs.
Stop using `ty::GenericPredicates` for non-predicates_of queries
`GenericPredicates` is a struct of several parts: A list of of an item's own predicates, and a parent def id (and some effects related stuff, but ignore that since it's kinda irrelevant). When instantiating these generic predicates, it calls `predicates_of` on the parent and instantiates its predicates, and appends the item's own instantiated predicates too:
acb4e8b625/compiler/rustc_middle/src/ty/generics.rs (L407-L413)
Notice how this should result in a recursive set of calls to `predicates_of`... However, `GenericPredicates` is *also* misused by a bunch of *other* queries as a convenient way of passing around a list of predicates. For these queries, we don't ever set the parent def id of the `GenericPredicates`, but if we did, then this would be very easy to mistakenly call `predicates_of` instead of some other intended parent query.
Given that footgun, and the fact that we don't ever even *use* the parent def id in the `GenericPredicates` returned from queries like `explicit_super_predicates_of`, It really has no benefit over just returning `&'tcx [(Clause<'tcx>, Span)]`.
This PR additionally opts to wrap the results of `EarlyBinder`, as we've tended to use that in the return type of these kinds of queries to properly convey that the user has params to deal with, and it also gives a convenient way of iterating over a slice of things after instantiating.
Remove `Option<!>` return types.
Several compiler functions have `Option<!>` for their return type. That's odd. The only valid return value is `None`, so why is this type used?
Because it lets you write certain patterns slightly more concisely. E.g. if you have these common patterns:
```
let Some(a) = f() else { return };
let Ok(b) = g() else { return };
```
you can shorten them to these:
```
let a = f()?;
let b = g().ok()?;
```
Huh.
An `Option` return type typically designates success/failure. How should I interpret the type signature of a function that always returns (i.e. doesn't panic), does useful work (modifying `&mut` arguments), and yet only ever fails? This idiom subverts the type system for a cute syntactic trick.
Furthermore, returning `Option<!>` from a function F makes things syntactically more convenient within F, but makes things worse at F's callsites. The callsites can themselves use `?` with F but should not, because they will get an unconditional early return, which is almost certainly not desirable. Instead the return value should be ignored. (Note that some of callsites of `process_operand`, `process_immedate`, `process_assign` actually do use `?`, though the early return doesn't matter in these cases because nothing of significance comes after those calls. Ugh.)
When I first saw this pattern I had no idea how to interpret it, and it took me several minutes of close reading to understand everything I've written above. I even started a Zulip thread about it to make sure I understood it properly. "Save a few characters by introducing types so weird that compiler devs have to discuss it on Zulip" feels like a bad trade-off to me. This commit replaces all the `Option<!>` return values and uses `else`/`return` (or something similar) to replace the relevant `?` uses. The result is slightly more verbose but much easier to understand.
r? ``````@cjgillot``````
Simplify some extern providers
Simplifies some extern crate providers:
1. Generalize the `ProcessQueryValue` identity impl to work on non-`Option` types.
2. Allow `ProcessQueryValue` to wrap its output in an `EarlyBinder`, to simplify `explicit_item_bounds`/`explicit_item_super_predicates`.
3. Use `{ table }` and friends more when possible.
Deny `wasm_c_abi` lint to nudge the last 25%
This shouldn't affect projects indirectly depending on wasm-bindgen because cargo passes `--cap-lints=allow` when building dependencies.
The motivation is that the ecosystem has mostly taken up the versions of wasm-bindgen that are compatible in general, but ~25% or so of recent downloads remain on lower versions. However, this change might still be unnecessarily disruptive. I mostly propose it as a discussion point.
linker: Synchronize native library search in rustc and linker
Also search for static libraries with alternative naming (`libname.a`) on MSVC when producing executables or dynamic libraries, and not just rlibs.
This unblocks https://github.com/rust-lang/rust/pull/123436.
try-job: x86_64-msvc
Don't make statement nonterminals match pattern nonterminals
Right now, the heuristic we use to check if a token may begin a pattern nonterminal falls back to `may_be_ident`:
ef71f1047e/compiler/rustc_parse/src/parser/nonterminal.rs (L21-L37)
This has the unfortunate side effect that a `stmt` nonterminal eagerly matches against a `pat` nonterminal, leading to a parse error:
```rust
macro_rules! m {
($pat:pat) => {};
($stmt:stmt) => {};
}
macro_rules! m2 {
($stmt:stmt) => {
m! { $stmt }
};
}
m2! { let x = 1 }
```
This PR fixes it by more accurately reflecting the set of nonterminals that may begin a pattern nonterminal.
As a side-effect, I modified `Token::can_begin_pattern` to work correctly and used that in `Parser::nonterminal_may_begin_with`.
We want to allow setting this on the CLI, override it only in MIR
passes, and disable it altogether in mir-opt tests.
The default value is "only for NLL MIR dumps", which is considered off
for all intents and purposes, except for `rustc_borrowck` when an NLL
MIR dump is requested.
Several compiler functions have `Option<!>` for their return type.
That's odd. The only valid return value is `None`, so why is this type
used?
Because it lets you write certain patterns slightly more concisely. E.g.
if you have these common patterns:
```
let Some(a) = f() else { return };
let Ok(b) = g() else { return };
```
you can shorten them to these:
```
let a = f()?;
let b = g().ok()?;
```
Huh.
An `Option` return type typically designates success/failure. How should
I interpret the type signature of a function that always returns (i.e.
doesn't panic), does useful work (modifying `&mut` arguments), and yet
only ever fails? This idiom subverts the type system for a cute
syntactic trick.
Furthermore, returning `Option<!>` from a function F makes things
syntactically more convenient within F, but makes things worse at F's
callsites. The callsites can themselves use `?` with F but should not,
because they will get an unconditional early return, which is almost
certainly not desirable. Instead the return value should be ignored.
(Note that some of callsites of `process_operand`, `process_immedate`,
`process_assign` actually do use `?`, though the early return doesn't
matter in these cases because nothing of significance comes after those
calls. Ugh.)
When I first saw this pattern I had no idea how to interpret it, and it
took me several minutes of close reading to understand everything I've
written above. I even started a Zulip thread about it to make sure I
understood it properly. "Save a few characters by introducing types so
weird that compiler devs have to discuss it on Zulip" feels like a bad
trade-off to me. This commit replaces all the `Option<!>` return values
and uses `else`/`return` (or something similar) to replace the relevant
`?` uses. The result is slightly more verbose but much easier to
understand.
This keeps it up-to-date by moving from 0.5.6 to 0.5.7. While here I've
additionally updated some other wasm-related dependencies in the
workspace to keep them up-to-date and try to avoid duplicate versions as
well.
Use a reduced recursion limit in the MIR inliner's cycle breaker
This probably papers over https://github.com/rust-lang/rust/issues/128887, but primarily I'm opening this PR because multiple compiler people have thought about making this change which probably means it's a good idea.
r? compiler-errors
