| Age | Commit message (Collapse) | Author | Lines |
|---|
|
accesses
|
|
fix: Improve parser recovery a bit
|
|
|
|
Rollup of 11 pull requests
Successful merges:
- #136160 (Remove backticks from `ShouldPanic::YesWithMessage`'s `TrFailedMsg`)
- #139059 (uses_power_alignment: wording tweaks)
- #139192 (mention provenance in the pointer::wrapping_offset docs)
- #140312 (Improve pretty-printing of braces)
- #140404 (rm `TypeVistable` impls for `Canonical`)
- #140437 (enable msa feature for mips in codegen tests)
- #140438 (Add `rust.debug-assertions-tools` option)
- #140439 (miri: algebraic intrinsics: bring back float non-determinism)
- #140445 (Treat ManuallyDrop as ~const Destruct)
- #140446 (chore: fix some tests)
- #140448 (Rename `rustc_query_append!` to `rustc_with_all_queries!`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
fix: Correct span info for mir::Operand
|
|
chore: fix some tests
|
|
miri: algebraic intrinsics: bring back float non-determinism
Fixes https://github.com/rust-lang/miri/issues/4289
Cc ```@bjoernager```
r? ```@oli-obk```
|
|
|
|
|
|
Co-authored-by: est31 <est31@users.noreply.github.com>
|
|
|
|
Does not do much yet due to tracing pulling syn but oh well
|
|
|
|
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`
|
|
Make thread scheduling fully random
|
|
|
|
|
|
|
|
refactor: Remove unnecessary extension trait
|
|
|
|
|
|
refactor: Cleanup cfg check handling in expression store lowering
|
|
Add PGO support to install
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
fix: Escape raw names in labels properly
|
|
|
|
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
|
|
refactor: De-arc lang item queries
|
|
refactor: migrate `let_else_to_match` to editor
|
|
|
|
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.
|
|
Co-authored-by: Tarek <tareknaser360@gmail.com>
Signed-off-by: Prajwal S N <prajwalnadig21@gmail.com>
|
|
Signed-off-by: Prajwal S N <prajwalnadig21@gmail.com>
|
|
Also ensures that attributes on the use item are applied to the new use
item when unmerging.
Signed-off-by: Prajwal S N <prajwalnadig21@gmail.com>
|
|
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.
|
|
Signed-off-by: Prajwal S N <prajwalnadig21@gmail.com>
|
|
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 a wrong error message in 2024 edition
Fixes https://github.com/rust-lang/rust/issues/139952
|
|
|
|
fix: Address minor FIXME
|
|
|
|
Add expression fill mode variant for filling with underscore expressions
|
