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.
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
compiletest: Remove the libtest-based executor and its dependency
Now that #140288 has landed and the new compiletest executor is used by default, we can now move forward with removing the libtest dependency from compiletest.
My hope is that after landing this, we can configure bootstrap to build compiletest with the pre-built stage0 library by default, instead of the in-tree stage0 library. That would give the stage0 redesign one less thing to worry about.
---
This PR has deliberately been kept small and simple, to make it easier to revert if necessary. Further cleanup can take palce after we're confident that it won't need to be reverted.
r? jieyouxu
Blocker for https://github.com/rust-lang/rust/pull/119899
Enable `reliable_f16_math` on x86
This has been disabled due to an LLVM misoptimization with `powi.f16` [1]. This was fixed upstream and the fix is included in LLVM20, so tests no longer need to be disabled.
`f16` still remains disabled on MinGW due to the ABI issue.
[1]: https://github.com/llvm/llvm-project/issues/98665
try-job: x86_64-gnu
try-job: x86_64-gnu-llvm-19-1
try-job: x86_64-gnu-llvm-20-1
This has been disabled due to an LLVM misoptimization with `powi.f16`
[1]. This was fixed upstream and the fix is included in LLVM20, so tests
no longer need to be disabled.
`f16` still remains disabled on MinGW due to the ABI issue.
[1]: https://github.com/llvm/llvm-project/issues/98665
Extend the alignment check to borrows
The current alignment check does not include checks for creating misaligned references from raw pointers, which is now added in this patch.
When inserting the check we need to be careful with references to field projections (e.g. `&(*ptr).a`), in which case the resulting reference must be aligned according to the field type and not the type of the pointer.
r? `@saethlin`
cc `@RalfJung,` after our discussion in #134424
Specifically: `TokenCursor`, `TokenTreeCursor`,
`LazyAttrTokenStreamImpl`, `FlatToken`, `make_attr_token_stream`,
`ParserRange`, `NodeRange`. `ParserReplacement`, and `NodeReplacement`.
These are all related to token streams, rather than actual parsing.
This will facilitate the simplifications in the next commit.
With a recent change to the compiler, all instances of `#[naked]` must
now be wrapped in `#[unsafe(naked)]`. The `unwinding` crate, which is
used on Xous for doing unwinding in constrained environments, needed to
be updated to handle this change.
Bump the `unwinding` dependency to 0.2.6, which performs this wrapping.
Signed-off-by: Sean Cross <sean@xobs.io>
only return nested goals for `Certainty::Yes`
Ambiguous `NormalizesTo` goals can otherwise repeatedly add the same nested goals to the parent.
r? ```@compiler-errors```
Workaround for windows-gnu rust-lld test failure
The test run-make/amdgpu-kd has an issue on windows-gnu where rust-lld will sometimes fail with error 0xc0000374 (`STATUS_HEAP_CORRUPTION`).
This works around the issue by passing `--threads=1` to the linker as suggested [here](https://github.com/rust-lang/rust/issues/115985#issuecomment-1754112623). Note I don't know if this will help and it happens only sometimes in our CI so it's hard to test.
Rename sub_ptr to offset_from_unsigned in docs
There are still a few mentions of `sub_ptr` in comments and doc comments, which were missed in https://github.com/rust-lang/rust/pull/137483.
Implement the internal feature `cfg_target_has_reliable_f16_f128`
Support for `f16` and `f128` is varied across targets, backends, and backend versions. Eventually we would like to reach a point where all backends support these approximately equally, but until then we have to work around some of these nuances of support being observable.
Introduce the `cfg_target_has_reliable_f16_f128` internal feature, which provides the following new configuration gates:
* `cfg(target_has_reliable_f16)`
* `cfg(target_has_reliable_f16_math)`
* `cfg(target_has_reliable_f128)`
* `cfg(target_has_reliable_f128_math)`
`reliable_f16` and `reliable_f128` indicate that basic arithmetic for the type works correctly. The `_math` versions indicate that anything relying on `libm` works correctly, since sometimes this hits a separate class of codegen bugs.
These options match configuration set by the build script at [1]. The logic for LLVM support is duplicated as-is from the same script. There are a few possible updates that will come as a follow up.
The config introduced here is not planned to ever become stable, it is only intended to replace the build scripts for `std` tests and `compiler-builtins` that don't have any way to configure based on the codegen backend.
MCP: https://github.com/rust-lang/compiler-team/issues/866
Closes: https://github.com/rust-lang/compiler-team/issues/866
[1]: 555e1d0386/library/std/build.rs (L84-L186)
---
The second commit makes use of this config to replace `cfg_{f16,f128}{,_math}` in `library/`. I omitted providing a `cfg(bootstrap)` configuration to keep things simpler since the next beta branch is in two weeks.
try-job: aarch64-gnu
try-job: i686-msvc-1
try-job: test-various
try-job: x86_64-gnu
try-job: x86_64-msvc-ext2
Move inline asm check to typeck, properly handle aliases
Pull `InlineAsmCtxt` down to `rustc_hir_typeck`, and instead of using things like `Ty::is_copy`, use the `InferCtxt`-aware methods. To fix https://github.com/rust-lang/trait-system-refactor-initiative/issues/189, we also add a `try_structurally_resolve_*` call to `expr_ty`.
r? lcnr
Do not compute type_of for impl item if impl where clauses are unsatisfied
Consider the following code:
```rust
trait Foo {
fn call(self) -> impl Send;
}
trait Nested {}
impl<T> Foo for T
where
T: Nested,
{
fn call(self) -> impl Sized {
NotSatisfied.call()
}
}
struct NotSatisfied;
impl Foo for NotSatisfied {
fn call(self) -> impl Sized {
todo!()
}
}
```
In `impl Foo for NotSatisfied`, we need to prove that the RPITIT is well formed. This requires proving the item bound `<NotSatisfied as Foo>::RPITIT: Send`. Normalizing `<NotSatisfied as Foo>::RPITIT: Send` assembles two impl candidates, via the `NotSatisfied` impl and the blanket `T` impl. We end up computing the `type_of` for the blanket impl even if `NotSatisfied: Nested` where clause does not hold.
This type_of query ends up needing to prove that its own `impl Sized` RPIT satisfies `Send`, which ends up needing to compute the hidden type of the RPIT, which is equal to the return type of `NotSatisfied.call()`. That ends up in a query cycle, since we subsequently try normalizing that return type via the blanket impl again!
In the old solver, we don't end up computing the `type_of` an impl candidate if its where clauses don't hold, since this select call would fail before confirming the projection candidate:
d7ea436a02/compiler/rustc_trait_selection/src/traits/project.rs (L882)
This PR makes the new solver more consistent with the old solver by adding a call to `try_evaluate_added_goals` after regstering the impl predicates, which causes us to bail before computing the `type_of` for impls if the impl definitely doesn't apply.
r? lcnr
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/185
allow deref patterns to move out of boxes
This adds a case to lower deref patterns on boxes using a built-in deref instead of a `Deref::deref` or `DerefMut::deref_mut` call: if `deref!(inner): Box<T>` is matching on place `place`, the inner pattern `inner` now matches on `*place` rather than a temporary. No longer needing to call a method also means it won't borrow the scrutinee in match arms. This allows for bindings in `inner` to move out of `*place`.
For comparison with box patterns, this uses the same MIR lowering but different THIR. Consequently, deref patterns on boxes are treated the same as any other deref patterns in match exhaustiveness analysis. Box patterns can't quite be implemented in terms of deref patterns until exhaustiveness checking for deref patterns is implemented (I'll open a PR for exhaustiveness soon!).
Tracking issue: #87121
r? ``@Nadrieril``
Rollup of 7 pull requests
Successful merges:
- #140056 (Fix a wrong error message in 2024 edition)
- #140220 (Fix detection of main function if there are expressions around it)
- #140249 (Remove `weak` alias terminology)
- #140316 (Introduce `BoxMarker` to improve pretty-printing correctness)
- #140347 (ci: clean more disk space in codebuild)
- #140349 (ci: use aws codebuild for the `dist-x86_64-linux` job)
- #140379 (rustc-dev-guide subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
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
Async drop codegen
Async drop implementation using templated coroutine for async drop glue generation.
Scopes changes to generate `async_drop_in_place()` awaits, when async droppable objects are out-of-scope in async context.
Implementation details:
https://github.com/azhogin/posts/blob/main/async-drop-impl.md
New fields in Drop terminator (drop & async_fut). Processing in codegen/miri must validate that those fields are empty (in full version async Drop terminator will be expanded at StateTransform pass or reverted to sync version). Changes in terminator visiting to consider possible new successor (drop field).
ResumedAfterDrop messages for panic when coroutine is resumed after it is started to be async drop'ed.
Lang item for generated coroutine for async function async_drop_in_place. `async fn async_drop_in_place<T>()::{{closure0}}`.
Scopes processing for generate async drop preparations. Async drop is a hidden Yield, so potentially async drops require the same dropline preparation as for Yield terminators.
Processing in StateTransform: async drops are expanded into yield-point. Generation of async drop of coroutine itself added.
Shims for AsyncDropGlueCtorShim, AsyncDropGlue and FutureDropPoll.
```rust
#[lang = "async_drop"]
pub trait AsyncDrop {
#[allow(async_fn_in_trait)]
async fn drop(self: Pin<&mut Self>);
}
impl Drop for Foo {
fn drop(&mut self) {
println!("Foo::drop({})", self.my_resource_handle);
}
}
impl AsyncDrop for Foo {
async fn drop(self: Pin<&mut Self>) {
println!("Foo::async drop({})", self.my_resource_handle);
}
}
```
First async drop glue implementation re-worked to use the same drop elaboration code as for sync drop.
`async_drop_in_place` changed to be `async fn`. So both `async_drop_in_place` ctor and produced coroutine have their lang items (`AsyncDropInPlace`/`AsyncDropInPlacePoll`) and shim instances (`AsyncDropGlueCtorShim`/`AsyncDropGlue`).
```
pub async unsafe fn async_drop_in_place<T: ?Sized>(_to_drop: *mut T) {
}
```
AsyncDropGlue shim generation uses `elaborate_drops::elaborate_drop` to produce drop ladder (in the similar way as for sync drop glue) and then `coroutine::StateTransform` to convert function into coroutine poll.
AsyncDropGlue coroutine's layout can't be calculated for generic T, it requires known final dropee type to be generated (in StateTransform). So, `templated coroutine` was introduced here (`templated_coroutine_layout(...)` etc).
Such approach overrides the first implementation using mixing language-level futures in https://github.com/rust-lang/rust/pull/121801.
This patch has deliberately been kept small and simple, to make it easier to
revert if necessary. Further cleanup can take palce after we're confident that
it won't need to be reverted.
