Rollup of 9 pull requests
Successful merges:
- #134232 (Share the naked asm impl between cg_ssa and cg_clif)
- #139624 (Don't allow flattened format_args in const.)
- #140090 (Check bare function idents for non snake-case name)
- #140203 (Issue an error when using `no_mangle` on language items)
- #140450 (ast: Remove token visiting from AST visitor)
- #140498 (Misc tweaks to HIR typeck (mostly w.r.t. checking calls))
- #140504 (transmutability: ensure_sufficient_stack when answering query)
- #140506 (unstable-book: fix capitalization)
- #140516 (Replace use of rustc_type_ir by rustc_middle)
Failed merges:
- #140374 (Resolve instance for SymFn in global/naked asm)
r? `@ghost`
`@rustbot` modify labels: rollup
Replace use of rustc_type_ir by rustc_middle
cc #138449
I want to help on this issue. I have replaced all the rustc_type_ir uses by the equivalent type in rustc_middle.
DelayedSet is also re-exposed by rustc_middle.
transmutability: ensure_sufficient_stack when answering query
Based on #140380.
Fixes#118860. The compile time was addressed earlier, this merely addresses stack overflow part of the issue.
r? `@jswrenn` `@joshlf`
Issue an error when using `no_mangle` on language items
This pull requests adds the code to issue an error or a warning when using `no_mangle` on language items. This should detail why the `undefined symbol` error is issued for the code described in #139923.
The pull request adds two ui tests, one testing the error and the other one the warning.
I would love some feedback here, as I am not sure that the error and warning are issues using the right API.
Check bare function idents for non snake-case name
This PR adds the check required to lint on bare function idents for non snake-case name.
Reported at #140089.
cc `@theemathas`
Don't allow flattened format_args in const.
Fixes https://github.com/rust-lang/rust/issues/139136
Fixes https://github.com/rust-lang/rust/issues/139621
We allow `format_args!("a")` in const, but don't allow any format_args with arguments in const, such as `format_args!("{}", arg)`.
However, we accidentally allow `format_args!("hello {}", "world")` in const, as it gets flattened to `format_args!("hello world")`.
This also applies to panic in const.
This wasn't supposed to happen. I added protection against this in the format args flattening code, ~~but I accidentally marked a function as const that shouldn't have been const~~ but this was removed in https://github.com/rust-lang/rust/pull/135139.
This is a breaking change. The crater found no breakage, however.
This breaks things like:
```rust
const _: () = if false { panic!("a {}", "a") };
```
and
```rust
const F: std::fmt::Arguments<'static> = format_args!("a {}", "a");
```
This commit does the following:
- Replaces use of rustc_type_ir by rustc_middle
- Removes the rustc_type_ir dependency
- The DelayedSet type is exposed by rustc_middle so everything can be
accessed through rustc_middle in a coherent manner.
add suggestion on how to add a panic breakpoint
Co-authored-by: Pat Pannuto <pat.pannuto@gmail.com>
delete no_mangle from ui/panic-handler/panic-handler-wrong-location test
issue an error for the usage of #[no_mangle] on internal language items
delete the comments
add newline
rephrase note
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
update error not to leak implementation details
delete no_mangle_span
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
delete commented code
Rename `rustc_query_append!` to `rustc_with_all_queries!`
Whenever I'm trying to make sense of the query system internals, I always get tripped up on this unhelpfully-named macro. The fact that it's a higher-order proc macro is already mind-melting enough on its own.
This new name, `rustc_with_all_queries!`, forms a much more intuitive combination with the helper macros that it invokes. And only one of the call sites was even making use of the “append” part of its old name.
This PR also reformats the parameters matched by the helper macros, to make the actual argument syntax a bit easier to see.
---
Renaming and reformatting only; no functional changes.
Add `rust.debug-assertions-tools` option
Before this PR, the two only options to configure the presence of debug assertions were the `rust.debug-assertions` and `rust.debug-assertions-std` options. The former applied to everything, and the latter allowed to override the setting just for the standard library. This combination of settings doesn't allow to enable debug assertions for the std and the compiler but not tools.
Some tools (like Cargo) are not really meant to be executed with debug assertions enabled, and in Ferrocene we hit some debug assertions in it that are exclusively meant for its test suite. We'd thus like to enable debug assertions everywhere but in tools.
This PR adds a `rust.debug-assertions-tools` setting that does exactly this.
rm `TypeVistable` impls for `Canonical`
similar to `EarlyBinder`, you generally do not want to fold a canonical value directly without first instantiating it. In places where you do want to look into the `Canonical`, it's likely better to do so manually.
r? ```@compiler-errors```
compiletest: Make diagnostic kind mandatory on line annotations (take 2)
Compiletest currently accepts line annotations without kind in UI tests.
```
let a = b + c; //~ my message
```
Such annotations have two effects.
- First, they match any compiler-produced diagnostic kind. This functionality is never used in practice, there are no target-dependent diagnostic kinds of something like that.
- Second, they are not "viral". For example, any explicit `//~ NOTE my msg` in a test requires all other `NOTE` diagnostics in the same test to be annotated. Implicit `//~ my msg` will just match the note and won't require other annotations.
The second functionality has a replacement since recently - directive `//@ dont-require-annotations: NOTE`.
This PR removes support for `//~ my message` and makes the explicit diagnostic kind mandatory.
Unwanted additional annotations are suppressed using the `dont-require-annotations` directive.
Closes https://github.com/rust-lang/compiler-team/issues/862.
Previous attempt - #139427.
r? `@jieyouxu`
Simplify `LazyAttrTokenStream`
`LazyAttrTokenStream` is an unpleasant type: `Lrc<Box<dyn ToAttrTokenStream>>`. Why does it look like that?
- There are two `ToAttrTokenStream` impls, one for the lazy case, and one for the case where we already have an `AttrTokenStream`.
- The lazy case (`LazyAttrTokenStreamImpl`) is implemented in `rustc_parse`, but `LazyAttrTokenStream` is defined in `rustc_ast`, which does not depend on `rustc_parse`. The use of the trait lets `rustc_ast` implicitly depend on `rustc_parse`. This explains the `dyn`.
- `LazyAttrTokenStream` must have a `size_of` as small as possible, because it's used in many AST nodes. This explains the `Lrc<Box<_>>`, which keeps it to one word. (It's required `Lrc<dyn _>` would be a fat pointer.)
This PR moves `LazyAttrTokenStreamImpl` (and a few other token stream things) from `rustc_parse` to `rustc_ast`. This lets us replace the `ToAttrTokenStream` trait with a two-variant enum and also remove the `Box`, changing `LazyAttrTokenStream` to `Lrc<LazyAttrTokenStreamInner>`. Plus it does a few cleanups.
r? `@petrochenkov`
This commit does the following.
- Changes it from `Lrc<Box<dyn ToAttrTokenStream>>` to
`Lrc<LazyAttrTokenStreamInner>`.
- Reworks `LazyAttrTokenStreamImpl` as `LazyAttrTokenStreamInner`, which
is a two-variant enum.
- Removes the `ToAttrTokenStream` trait and the two impls of it.
The recursion limit must be increased in some crates otherwise rustdoc
aborts.
Introduce Arena::try_alloc_from_iter.
`alloc_from_iter` already collects the iterator for reentrancy. So adding an early exit for a fallible iterator integrates naturally into the code. This avoids the other solution to allocate and dump the allocation.
The previous implementation was inconsistent about transitions that
apply for an init byte. For example, when answering a query, an init
byte could use corresponding init transition. Init byte could also use
uninit transition, but only when the corresponding init transition was
absent. This behaviour was incompatible with DFA union construction.
Define an uninit transition to match an uninit byte only and update
implementation accordingly. To describe that `Tree::uninit` is valid
for any value, build an automaton that accepts any byte value.
Additionally, represent byte ranges uniformly as a pair of integers to
avoid special case for uninit byte.
Replace the \01__gnu_mcount_nc to LLVM intrinsic for additional ARM targets
This is an extension to #113814 which seems to have missed two targets which also need this patch for instrumentation with `-Z instrument-mcount` to work correctly.
For anyone who might stumble over this issue again in the future: As a workaround one can dump the current target configuration using
```
rustc +nightly -Z unstable-options --target armv7-unknown-linux-gnueabihf --print target-spec-json
```
(assuming `armv7-unknown-linux-gnueabihf` is the target to build for) add the line
```
"llvm-mcount-intrinsic": "llvm.arm.gnu.eabi.mcount",
```
and compile with
```
RUSTFLAGS="-Z instrument-mcount -C passes=ee-instrument<post-inline>" cargo +nightly build -Z build-std --target <path to directory with modified target config>/armv7-unknown-linux-gnueabihf.json
```
It might be necessary to set the compiler for cross compiling using something like
```
export TARGET_CC=arm-linux-gnueabihf-gcc
```
unwind: bump `unwinding` dependency to 0.2.6
Xous now fails to compile under nightly, due to the recent change where `#[naked]` must now be wrapped in `unsafe(...)`. The `unwinding` crate was updated to account for this.
With the following `bootstrap.toml`:
```
profile = "library"
change-id = 138934
[build]
build-stage = 2
target = ["riscv32imac-unknown-xous-elf"]
[rust]
std-features = ["panic-unwind"]
download-rustc = false
```
The build fails when trying unwinding v0.2.5:
```
$ ./x.py build
[...]
Compiling unwinding v0.2.5
error: unsafe attribute used without unsafe
--> /home/user/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/unwinding-0.2.5/src/unwinder/arch/riscv32.rs:176:3
|
176 | #[naked]
| ^^^^^ usage of unsafe attribute
|
help: wrap the attribute in `unsafe(...)`
|
176 | #[unsafe(naked)]
| +++++++ +
error: could not compile `unwinding` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
Build completed unsuccessfully in 0:06:26
$
```
This patch updates `unwinding` to v0.2.6, which now wraps all issues of `naked` in `unsafe()`.
PassWrapper: adapt for llvm/llvm-project@d3d856ad84
LLVM 21 moves to making it more explicit what this function call is doing, but nothing has changed behaviorally, so for now we just adjust to using the new name of the function.
`@rustbot` label llvm-main
