| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Update documentation for `fn target_config`
This was missed as part of [1].
[1]: https://github.com/rust-lang/rust/pull/140323
|
|
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@d3d856ad8469
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
|
|
implement or-patterns for pattern types
These are necessary to represent `NonZeroI32`, as the range for that is `..0 | 1..`. The `rustc_scalar_layout_range_*` attributes avoided this by just implementing wraparound and having a single `1..=-1` range effectively. See https://rust-lang.zulipchat.com/#narrow/channel/481660-t-lang.2Fpattern-types/topic/.60or.20pattern.60.20representation.20in.20type.20system/with/504217694 for some background discussion
cc https://github.com/rust-lang/rust/issues/123646
r? `@BoxyUwU`
|
|
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
|
|
Miri subtree update
r? `@ghost`
|
|
Automatic Rustup
|
|
|
|
|
|
|
|
|
|
This was missed as part of [1].
[1]: https://github.com/rust-lang/rust/pull/140323
|
|
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
|
|
Rollup of 10 pull requests
Successful merges:
- #139308 (add autodiff inline)
- #139656 (Stabilize `slice_as_chunks` library feature)
- #140022 (allow deref patterns to move out of boxes)
- #140276 (Do not compute type_of for impl item if impl where clauses are unsatisfied)
- #140302 (Move inline asm check to typeck, properly handle aliases)
- #140323 (Implement the internal feature `cfg_target_has_reliable_f16_f128`)
- #140391 (Rename sub_ptr to offset_from_unsigned in docs)
- #140394 (Make bootstrap git tests more self-contained)
- #140396 (Workaround for windows-gnu rust-lld test failure)
- #140402 (only return nested goals for `Certainty::Yes`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
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.
|
|
Make bootstrap git tests more self-contained
Based on https://stackoverflow.com/a/67512433/1107768.
Fixes: https://github.com/rust-lang/rust/issues/140387
r? ```@jieyouxu```
|
|
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]: https://github.com/rust-lang/rust/blob/555e1d0386f024a8359645c3217f4b3eae9be042/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:
https://github.com/rust-lang/rust/blob/d7ea436a02d5de4033fcf7fd4eb8ed965d0f574c/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``
|
|
Stabilize `slice_as_chunks` library feature
~~Draft as this needs #139163 to land first.~~
FCP: https://github.com/rust-lang/rust/issues/74985#issuecomment-2769963395
Methods being stabilized are:
```rust
impl [T] {
const fn as_chunks<const N: usize>(&self) -> (&[[T; N]], &[T]);
const fn as_rchunks<const N: usize>(&self) -> (&[T], &[[T; N]]);
const unsafe fn as_chunks_unchecked<const N: usize>(&self) -> &[[T; N]];
const fn as_chunks_mut<const N: usize>(&mut self) -> (&mut [[T; N]], &mut [T]);
const fn as_rchunks_mut<const N: usize>(&mut self) -> (&mut [T], &mut [[T; N]]);
const unsafe fn as_chunks_unchecked_mut<const N: usize>(&mut self) -> &mut [[T; N]];
}
```
~~(FCP's not done quite yet, but will in another day if I'm counting right.)~~ FCP Complete: https://github.com/rust-lang/rust/issues/74985#issuecomment-2797951535
|
|
add autodiff inline
closes: #138920
r? ```@ZuseZ4```
try-job: dist-aarch64-linux
|
|
The test run-make/amdgpu-kd has an issue where rust-lld will sometimes fail with error 0xc0000374 (STATUS_HEAP_CORRUPTION).
|
|
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 makes the implementation of our PointerFinder a bit more
straightforward.
|
|
|
|
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.
|
|
rustc-dev-guide subtree update
|
|
ci: use aws codebuild for the `dist-x86_64-linux` job
try-job: dist-x86_64-linux
|
|
ci: clean more disk space in codebuild
try-job: dist-arm-linux
|
|
Introduce `BoxMarker` to improve pretty-printing correctness
Box opening/closing is really easy to get wrong in the pretty-printers. This PR makes it much harder to get wrong.
r? `@Urgau`
|
|
Remove `weak` alias terminology
I find the "weak" alias terminology to be quite confusing. It implies the existence of "strong" aliases (which do not exist) and I'm not really sure what about weak aliases is "weak". I much prefer "free alias" as the term. I think it's much more obvious what it means as "free function" is a well defined term that already exists in rust.
It's also a little confusing given "weak alias" is already a term in linker/codegen spaces which are part of the compiler too. Though I'm not particularly worried about that as it's usually very obvious if you're talking about the type system or not lol. I'm also currently trying to write documentation about aliases and it's somewhat awkward/confusing to be talking about *weak* aliases, when I'm not really sure what the basis for that as the term actually *is*.
I would also be happy to just find out there's a nice meaning behind calling them "weak" aliases :-)
r? `@oli-obk`
maybe we want a types MCP to decide on a specific naming here? or maybe we think its just too late to go back on this naming decision ^^'
|
|
Fix detection of main function if there are expressions around it
Fixes #140162.
Fixes #139651.
Once this is merged, we can backport and I'll send a follow-up to emit a warning in case a `main` function is about to be "wrapped" (and therefore not run).
r? `@fmease`
try-job: x86_64-mingw-1
|
|
Fix a wrong error message in 2024 edition
Fixes https://github.com/rust-lang/rust/issues/139952
|
|
async_drop_in_place::{closure}, scoped async drop added.
|
|
r=jdonszelmann,traviscross
Implement a lint for implicit autoref of raw pointer dereference - take 2
*[t-lang nomination comment](https://github.com/rust-lang/rust/pull/123239#issuecomment-2727551097)*
This PR aims at implementing a lint for implicit autoref of raw pointer dereference, it is based on #103735 with suggestion and improvements from https://github.com/rust-lang/rust/pull/103735#issuecomment-1370420305.
The goal is to catch cases like this, where the user probably doesn't realise it just created a reference.
```rust
pub struct Test {
data: [u8],
}
pub fn test_len(t: *const Test) -> usize {
unsafe { (*t).data.len() } // this calls <[T]>::len(&self)
}
```
Since #103735 already went 2 times through T-lang, where they T-lang ended-up asking for a more restricted version (which is what this PR does), I would prefer this PR to be reviewed first before re-nominating it for T-lang.
----
Compared to the PR it is as based on, this PR adds 3 restrictions on the outer most expression, which must either be:
1. A deref followed by any non-deref place projection (that intermediate deref will typically be auto-inserted)
2. A method call annotated with `#[rustc_no_implicit_refs]`.
3. A deref followed by a `addr_of!` or `addr_of_mut!`. See bottom of post for details.
There are several points that are not 100% clear to me when implementing the modifications:
- ~~"4. Any number of automatically inserted deref/derefmut calls." I as never able to trigger this. Am I missing something?~~ Fixed
- Are "index" and "field" enough?
----
cc `@JakobDegen` `@WaffleLapkin`
r? `@RalfJung`
try-job: dist-various-1
try-job: dist-various-2
|
|
|
|
|
