| Age | Commit message (Collapse) | Author | Lines |
|---|
|
merge core_panic feature into panic_internals
I don't know why those are two separate features, but it does not seem intentional. This merge is useful because with https://github.com/rust-lang/rust/pull/118123, panic_internals is recognized as an internal feature, but core_panic is not -- but core_panic definitely should be internal.
|
|
LLVM currently don't support range metadata for function arguments so it fails to optimize non zero integers using their invariant if they are provided using by-value function arguments.
Related to https://github.com/rust-lang/rust/issues/119422
Related to https://github.com/llvm/llvm-project/issues/76628
Related to https://github.com/rust-lang/rust/issues/49572
|
|
|
|
|
|
r=compiler-errors
Use diagnostic namespace in stdlib
This required a minor fix to have the diagnostics shown in third party crates when the `diagnostic_namespace` feature is not enabled. See https://github.com/rust-lang/rust/pull/119216/commits/5d63f5d8d1a72167c1d5242b2e1ed5b7259fd526 for details. I've opted for having a single PR for both changes as it's really not that much code. If it is required it should be easy to split up the change into several PR's.
r? `@compiler-errors`
|
|
The feature does not seem to be required by this doctest.
|
|
The lint is not yet reported due to span issues, but will be reported later.
|
|
Make `intrinsics::assume` const stable
Closes https://github.com/rust-lang/rust/issues/76972
Blocks https://github.com/rust-lang/rust/pull/119452
Approved in https://github.com/rust-lang/rust/pull/119452#issuecomment-1875741678
r? `@RalfJung`
|
|
accumulating value outside of the fold in an attempt to improve code generation
Squashed with: Add inheriting overflow checks back
|
|
`#[diagnostic::on_unimplemented]`
This commit replaces those `#[rustc_on_unimplemented]` attributes with
their equivalent `#[diagnostic::on_unimplemented]` where this is
supported (So no filter or any extended option)
|
|
Merge `unused_tuple_struct_fields` into `dead_code`
This implicitly upgrades the lint from `allow` to `warn` and places it into the `unused` lint group.
[Discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Moving.20.60unused_tuple_struct_fields.60.20from.20allow.20to.20warn)
|
|
|
|
Needle and haystack are actually not the same, they remain constant.
|
|
Closes https://github.com/rust-lang/rust/issues/76972
Blocks https://github.com/rust-lang/rust/pull/119452
Approved in https://github.com/rust-lang/rust/pull/119452#issuecomment-1875741678
|
|
Make offset_of field parsing use metavariable which handles any spacing
As discussed at and around comments https://github.com/rust-lang/rust/issues/106655#issuecomment-1793485081 and https://github.com/rust-lang/rust/issues/106655#issuecomment-1793774183, the current arguments to offset_of do not accept all the whitespace combinations: `0. 1.1.1` and `0.1.1. 1` are currently treated specially in `tests/ui/offset-of/offset-of-tuple-nested.rs`.
They also do not allow [forwarding individual fields as in](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=444cdf0ec02b99e8fd5fd8d8ecb312ca)
```rust
macro_rules! off {
($a:expr) => {
offset_of!(m::S, 0. $a)
}
}
```
This PR replaces the macro arguments with `($Container:ty, $($fields:expr)+ $(,)?)` which does allow any arrangement of whitespace that I could come up with and the forwarding of fields example above.
This also allows for array indexing in the future, which I think is the last future extension to the syntax suggested in the offset_of RFC.
Tracking issue for offset_of: #106655
``@rustbot`` label F-offset_of
``@est31``
|
|
custom mir: make it clear what the return block is
Custom MIR recently got support for specifying the "unwind action", so now there's two things coming after the actual call part of `Call` terminators. That's not very self-explaining so I propose we change the syntax to imitate keyword arguments:
```
Call(popped = Vec::pop(v), ReturnTo(drop), UnwindContinue())
```
Also fix some outdated docs and add some docs to `Call` and `Drop`.
|
|
|
|
|
|
|
|
|
|
Primitive docs: fix confusing `Send` in `&T`'s list
The two lists in this document describe what traits are implemented on references when their underlying `T` also implements them. However, while it is true that `T: Send + Sync` implies `&T: Send` (which is what the sentence is trying to explain), it is confusing to have `Send` in the list because `T: Send` is not needed for that. In particular, the "also require" part may be interpreted as "both `T: Send` and `T: Sync` are required".
Instead, move `Send` back to where it was before commit 7a477869b72e ("Makes docs for references a little less confusing"), i.e. to the `&mut` list (where no extra nota is needed, i.e. it fits naturally) and move the `Sync` definition/note to the bottom as something independent.
|
|
The two lists in this document describe what traits are implemented on
references when their underlying `T` also implements them. However,
while it is true that `T: Send + Sync` implies `&T: Send` (which is
what the sentence is trying to explain), it is confusing to have `Send`
in the list because `T: Send` is not needed for that. In particular,
the "also require" part may be interpreted as "both `T: Send` and
`T: Sync` are required".
Instead, move `Send` back to where it was before commit 7a477869b72e
("Makes docs for references a little less confusing"), i.e. to the `&mut`
list (where no extra nota is needed, i.e. it fits naturally) and move the
`Sync` definition/note to the bottom as something independent.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
|
|
|
|
|
|
|
|
impls exist
|
|
|
|
Add `hint::assert_unchecked`
Libs-API expressed interest, modulo bikeshedding, in https://github.com/rust-lang/libs-team/issues/315#issuecomment-1863159430
I think that means this is good for nightly, since we can always rename it before stabilization.
Tracking issue: https://github.com/rust-lang/rust/issues/119131
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add `IntoAsyncIterator`
This introduces the `IntoAsyncIterator` trait and uses it in the desugaring of the unstable `for await` loop syntax. This is mostly added for symmetry with `Iterator` and `IntoIterator`.
r? `@compiler-errors`
cc `@rust-lang/libs-api,` `@rust-lang/wg-async`
|
|
Bump stage0 to 1.76 beta
r? `@Mark-Simulacrum`
|
|
|
|
|
|
Add support for `for await` loops
This adds support for `for await` loops. This includes parsing, desugaring in AST->HIR lowering, and adding some support functions to the library.
Given a loop like:
```rust
for await i in iter {
...
}
```
this is desugared to something like:
```rust
let mut iter = iter.into_async_iter();
while let Some(i) = loop {
match core::pin::Pin::new(&mut iter).poll_next(cx) {
Poll::Ready(i) => break i,
Poll::Pending => yield,
}
} {
...
}
```
This PR also adds a basic `IntoAsyncIterator` trait. This is partly for symmetry with the way `Iterator` and `IntoIterator` work. The other reason is that for async iterators it's helpful to have a place apart from the data structure being iterated over to store state. `IntoAsyncIterator` gives us a good place to do this.
I've gated this feature behind `async_for_loop` and opened #118898 as the feature tracking issue.
r? `@compiler-errors`
|
|
|
|
|
|
do not allow ABI mismatches inside repr(C) types
In https://github.com/rust-lang/rust/pull/115476 we allowed ABI mismatches inside `repr(C)` types. This wasn't really discussed much; I added it because from how I understand calling conventions, this should actually be safe in practice. However I entirely forgot to actually allow this in Miri, and in the mean time I have learned that too much ABI compatibility can be a problem for CFI (it can reject fewer calls so that gives an attacker more room to play with).
So I propose we take back that part about ABI compatibility in `repr(C)`. It is anyway something that C and C++ do not allow, as far as I understand.
In the future we might want to introduce a class of ABI compatibilities where we say "this is a bug and it may lead to aborting the process, but it won't lead to arbitrary misbehavior -- worst case it'll just transmute the arguments from the caller type to the callee type". That would give CFI leeway to reject such calls without introducing the risk of arbitrary UB. (The UB can still happen if the transmute leads to bad results, of course, but it wouldn't be due to ABI weirdness.)
#115476 hasn't reached beta yet so if we land this before Dec 22nd we can just pretend this all never happened. ;) Otherwise we should do a beta backport (of the docs change at least).
Cc `@rust-lang/opsem` `@rust-lang/types`
|
|
|
|
I done this for this reasons:
1. The example now shows that there is more Orderings than just SeqCst.
2. People who would copy from example would now have more suitable orderings for the job.
3. SeqCst is both much harder to reason about and not needed in most situations.
IMHO, we should encourage people to think and use memory orderings that is suitable to task instead of blindly defaulting to SeqCst.
|
|
|
|
|
|
This change consists of cherry-picking the content from the original
PR[1], which got closed due to inactivity, and applying the following
changes:
* Resolving merge conflicts (obviously)
* Linked to to_ipv4_mapped instead of to_ipv4 in the documentation (seems
more appropriate)
* Added the must_use and rustc_const_unstable attributes the original
didn't have
I think it's a reasonably useful method.
[1] https://github.com/rust-lang/rust/pull/86490
|
|
|
|
|
