| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Because that causes an assertion failure in debug builds.
Fixes #140884.
(cherry picked from commit 1cc0e38fdc4d2ec8c9c130d7ffc9c30d100885a2)
|
|
This fixes a perf regression introduced in #140252.
(cherry picked from commit 4cb9f0309d6e85e6d4bef42321b06ad299e3ef27)
|
|
All uses have been removed. And it's nonsensical: an identifier by
definition has at least one char.
The commits adds an is-non-empty assertion to `Ident::new` to enforce
this, and converts some `Ident` constructions to use `Ident::new`.
Adding the assertion requires making `Ident::new` and
`Ident::with_dummy_span` non-const, which is no great loss.
The commit amends a couple of places that do path splitting to ensure no
empty identifiers are created.
|
|
Move `in_external_macro` to `SyntaxContext`
There are a few places in clippy where spans are passed solely to use the context, but we can't pass just the context around because of this function.
|
|
r=workingjubilee
Added support for `apxf` target feature
|
|
|
|
r=jieyouxu,wesleywiser
Implement RFC 3503: frontmatters
Tracking issue: #136889
Supercedes #137193. This implements [RFC 3503](https://github.com/rust-lang/rfcs/blob/master/text/3503-frontmatter.md).
This might break rust-analyzer. Will look into how to fix that.
Suggestions welcome for how to improve diagnostics.
|
|
Fix `-Zremap-path-scope` rmeta handling
This PR fixes the conditional remapping (`-Zremap-path-scope`) of rmeta file paths ~~by using the `debuginfo` scope~~ by conditionally embedding the local path in addition to the remapped path.
Fixes https://github.com/rust-lang/rust/issues/139217
|
|
|
|
Supercedes #137193
|
|
|
|
Add the AVX10 target features
Parent #138843
Adds the `avx10_target_feature` feature gate, and `avx10.1` and `avx10.2` target features.
It is confirmed that Intel is dropping AVX10/256 (see [this comment](https://github.com/rust-lang/rust/issues/111137#issuecomment-2795442288)), so this should be safe to implement now.
The LLVM fix for llvm/llvm-project#135394 was merged, and has been backported to LLVM20, and the patch has also been propagated to rustc in #140502
`@rustbot` label O-x86_64 O-x86_32 A-target-feature A-SIMD
|
|
Optimize the codegen for `Span::from_expansion`
See https://godbolt.org/z/bq65Y6bc4 for the difference. the new version is less than half the number of instructions.
Also tried fully writing the function by hand:
```rust
sp.ctxt_or_parent_or_marker != 0
&& (
sp.len_with_tag_or_marker == BASE_LEN_INTERNED_MARKER
|| sp.len_with_tag_or_marker & PARENT_TAG == 0
)
```
But that was no better than this PR's current use of `match_span_kind`.
|
|
Rather than marking the Argument::new_display etc. functions as
non-const, this marks the Arguments::new_v1 functions as non-const.
|
|
|
|
|
|
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
|
|
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
|
|
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.
|
|
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
|
|
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
|
|
|
|
Inline some functions used once.
Use `impl Trait` more.
Tweak some comments.
|
|
They are no longer necessary after #139281
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #137683 (Add a tidy check for GCC submodule version)
- #138968 (Update the index of Result to make the summary more comprehensive)
- #139572 (docs(std): mention const blocks in const keyword doc page)
- #140152 (Unify the format of rustc cli flags)
- #140193 (fix ICE in `#[naked]` attribute validation)
- #140205 (Tidying up UI tests [2/N])
- #140284 (remove expect() in `unnecessary_transmutes`)
- #140290 (rustdoc: fix typo change from equivelent to equivalent)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
|
|
It was only temporarily used by pin!(), which no longer needs it.
|
|
Rewrite on_unimplemented format string parser.
This PR rewrites the format string parser for `rustc_on_unimplemented` and `diagnostic::on_unimplemented`. I plan on moving this code (and more) into the new attribute parsing system soon and wanted to PR it separately.
This PR introduces some minor differences though:
- `rustc_on_unimplemented` on trait *implementations* is no longer checked/used - this is actually never used (outside of some tests) so I plan on removing it in the future.
- for `rustc_on_unimplemented`, it introduces the `{This}` argument in favor of `{ThisTraitname}` (to be removed later). It'll be easier to parse.
- for `rustc_on_unimplemented`, `Self` can now consistently be used as a filter, rather than just `_Self`. It used to not match correctly on for example `Self = "[{integer}]"`
- Some error messages now have better spans.
Fixes https://github.com/rust-lang/rust/issues/130627
|
|
Implement `pin!()` using `super let`
Tracking issue for super let: https://github.com/rust-lang/rust/issues/139076
This uses `super let` to implement `pin!()`.
This means we can remove [the hack](https://github.com/rust-lang/rust/pull/138717) we had to put in to fix https://github.com/rust-lang/rust/issues/138596.
It also means we can remove the original hack to make `pin!()` work, which used a questionable public-but-unstable field rather than a proper private field.
While `super let` is still unstable and subject to change, it seems safe to assume that future Rust will always have a way to express `pin!()` in a compatible way, considering `pin!()` is already stable.
It'd help [the experiment](https://github.com/rust-lang/rust/issues/139076) to have `pin!()` use `super let`, so we can get some more experience with it.
|
|
Remove `name_or_empty`
Another step towards #137978.
r? ``@jdonszelmann``
|
|
Rollup of 9 pull requests
Successful merges:
- #135340 (Add `explicit_extern_abis` Feature and Enforce Explicit ABIs)
- #139440 (rustc_target: RISC-V: feature addition batch 2)
- #139667 (cfi: Remove #[no_sanitize(cfi)] for extern weak functions)
- #139828 (Don't require rigid alias's trait to hold)
- #139854 (Improve parse errors for stray lifetimes in type position)
- #139889 (Clean UI tests 3 of n)
- #139894 (Fix `opt-dist` CLI flag and make it work without LLD)
- #139900 (stepping into impls for normalization is unproductive)
- #139915 (replace some #[rustc_intrinsic] usage with use of the libcore declarations)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
I'm removing empty identifiers everywhere, because in practice they
always mean "no identifier" rather than "empty identifier". (An empty
identifier is impossible.) It's better to use `Option` to mean "no
identifier" because you then can't forget about the "no identifier"
possibility.
Some specifics:
- When testing an attribute for a single name, the commit uses the
`has_name` method.
- When testing an attribute for multiple names, the commit uses the new
`has_any_name` method.
- When using `match` on an attribute, the match arms now have `Some` on
them.
In the tests, we now avoid printing empty identifiers by not printing
the identifier in the `error:` line at all, instead letting the carets
point out the problem.
|
|
Add `explicit_extern_abis` Feature and Enforce Explicit ABIs
The unstable `explicit_extern_abis` feature is introduced, requiring explicit ABIs in `extern` blocks. Hard errors will be enforced with this feature enabled in a future edition.
RFC rust-lang/rfcs#3722
Update #134986
|
|
hygiene: Rename semi-transparent to semi-opaque
"Semi-transparent" is just too damn long for a name, especially when used multiple times on a single line, it bothered me when working on #139083.
An optimist sees a macro as semi-opaque, a pessimist sees it as semi-transparent.
Or is it the other way round?
|
|
Because it's equivalent to `#[rustc_mir(borrowck_graphviz_format)]`. It
used to be distinct, but the distinction was removed in
https://github.com/rust-lang/rust/pull/76044/commits/3233fb18a891363a2da36ce69ca16fbb219c96be.
|
|
also add `explicit-extern-abis` feature section to
the unstable book.
|
|
|
|
don't store opaque info during encoding
Now `remapped_ctxts` reserved and let's check the performance.
r? `@petrochenkov`
|
|
|
|
Suggest remove redundant `$()?` around `vis`
Resolves: #139480 .
|
|
r=traviscross,compiler-errors
add `naked_functions_rustic_abi` feature gate
tracking issue: https://github.com/rust-lang/rust/issues/138997
Because the details of the rust abi are unstable, and a naked function must match its stated ABI, this feature gate keeps naked functions with a rustic abi ("Rust", "rust-cold", "rust-call" and "rust-intrinsic") unstable.
r? ````@traviscross````
|
|
|
|
|
|
Tweak `DefPathData`
Some improvements in and around `DefPathData`, following on from #137977.
r? `@spastorino`
|
|
Give them their own symbol `anon_assoc`, as is done for all the other
anonymous `DefPathData` variants.
|
|
|
