| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 6 pull requests
Successful merges:
- #131200 (Handle `rustc_query_system` cases of `rustc::potential_query_instability` lint)
- #141244 (windows: document that we rely on an undocumented property of GetUserProfileDirectoryW)
- #141247 (skip compiler tools sanity checks on certain commands)
- #141248 (fix data race in ReentrantLock fallback for targets without 64bit atomics)
- #141249 (introduce common macro for `MutVisitor` and `Visitor` to dedup code)
- #141253 (Warning added when dependency crate has async drop types, and the feature is disabled)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
disabled
|
|
in `tests/ui/asm/aarch64/parse-error.rs`, only test cases specific to that target
this is more in line with the x86 parse error tests at https://github.com/rust-lang/rust/blob/master/tests/ui/asm/x86_64/x86_64_parse_error.rs. We could at this point use minicore so that these tests run no matter the host target?
`tests/ui/asm/aarch64/parse-error.rs` was mostly a copy of https://github.com/rust-lang/rust/blob/master/tests/ui/asm/parse-error.rs, though a bit out of date. The only aarch64-specific tests are those that talk about register names. Here is a diff between those two files:
```diff
--- <unnamed>
+++ <unnamed>
`@@` -1,4 +1,4 `@@`
-//@ needs-asm-support
+//@ only-aarch64
use std::arch::{asm, global_asm};
`@@` -36,36 +36,12 `@@`
//~^ ERROR expected one of
asm!("{}", options(), const foo);
//~^ ERROR attempt to use a non-constant value in a constant
-
- // test that asm!'s clobber_abi doesn't accept non-string literals
- // see also https://github.com/rust-lang/rust/issues/112635
- asm!("", clobber_abi());
- //~^ ERROR at least one abi must be provided
asm!("", clobber_abi(foo));
//~^ ERROR expected string literal
asm!("", clobber_abi("C" foo));
//~^ ERROR expected one of `)` or `,`, found `foo`
asm!("", clobber_abi("C", foo));
//~^ ERROR expected string literal
- asm!("", clobber_abi(1));
- //~^ ERROR expected string literal
- asm!("", clobber_abi(()));
- //~^ ERROR expected string literal
- asm!("", clobber_abi(uwu));
- //~^ ERROR expected string literal
- asm!("", clobber_abi({}));
- //~^ ERROR expected string literal
- asm!("", clobber_abi(loop {}));
- //~^ ERROR expected string literal
- asm!("", clobber_abi(if));
- //~^ ERROR expected string literal
- asm!("", clobber_abi(do));
- //~^ ERROR expected string literal
- asm!("", clobber_abi(<));
- //~^ ERROR expected string literal
- asm!("", clobber_abi(.));
- //~^ ERROR expected string literal
-
asm!("{}", clobber_abi("C"), const foo);
//~^ ERROR attempt to use a non-constant value in a constant
asm!("", options(), clobber_abi("C"));
`@@` -76,7 +52,15 `@@`
//~^^ ERROR argument never used
//~^^^ ERROR attempt to use a non-constant value in a constant
//~^^^^ ERROR attempt to use a non-constant value in a constant
-
+ asm!("", a = in("x0") foo);
+ //~^ ERROR explicit register arguments cannot have names
+ asm!("{a}", in("x0") foo, a = const bar);
+ //~^ ERROR attempt to use a non-constant value in a constant
+ asm!("{a}", in("x0") foo, a = const bar);
+ //~^ ERROR attempt to use a non-constant value in a constant
+ asm!("{1}", in("x0") foo, const bar);
+ //~^ ERROR positional arguments cannot follow named arguments or explicit register arguments
+ //~^^ ERROR attempt to use a non-constant value in a constant
asm!("", options(), "");
//~^ ERROR expected one of
asm!("{}", in(reg) foo, "{}", out(reg) foo);
`@@` -109,13 +93,11 `@@`
global_asm!("{}", const(reg) FOO);
//~^ ERROR expected one of
global_asm!("", options(FOO));
-//~^ ERROR expected one of `)`, `att_syntax`, or `raw`, found `FOO`
-global_asm!("", options(FOO,));
-//~^ ERROR expected one of `)`, `att_syntax`, or `raw`, found `FOO`
+//~^ ERROR expected one of
global_asm!("", options(nomem FOO));
-//~^ ERROR expected one of `)` or `,`, found `FOO`
+//~^ ERROR expected one of
global_asm!("", options(nomem, FOO));
-//~^ ERROR expected one of `)`, `att_syntax`, or `raw`, found `FOO`
+//~^ ERROR expected one of
global_asm!("{}", options(), const FOO);
global_asm!("", clobber_abi(FOO));
//~^ ERROR expected string literal
`@@` -129,8 +111,6 `@@`
//~^ ERROR `clobber_abi` cannot be used with `global_asm!`
global_asm!("{}", options(), clobber_abi("C"), const FOO);
//~^ ERROR `clobber_abi` cannot be used with `global_asm!`
-global_asm!("", clobber_abi("C"), clobber_abi("C"));
-//~^ ERROR `clobber_abi` cannot be used with `global_asm!`
global_asm!("{a}", a = const FOO, a = const BAR);
//~^ ERROR duplicate argument named `a`
//~^^ ERROR argument never used
`@@` -142,16 +122,3 `@@`
//~^ ERROR asm template must be a string literal
global_asm!("{1}", format!("{{{}}}", 0), const FOO, const BAR);
//~^ ERROR asm template must be a string literal
-
-global_asm!("{}", in(reg));
-//~^ ERROR the `in` operand cannot be used with `global_asm!`
-global_asm!("{}", out(reg));
-//~^ ERROR the `out` operand cannot be used with `global_asm!`
-global_asm!("{}", lateout(reg));
-//~^ ERROR the `lateout` operand cannot be used with `global_asm!`
-global_asm!("{}", inout(reg));
-//~^ ERROR the `inout` operand cannot be used with `global_asm!`
-global_asm!("{}", inlateout(reg));
-//~^ ERROR the `inlateout` operand cannot be used with `global_asm!`
-global_asm!("{}", label(reg));
-//~^ ERROR the `label` operand cannot be used with `global_asm!`
```
|
|
more ice tests
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-gnu
try-job: dist-i586-gnu-i586-i686-musl
try-job: test-various
|
|
coverage: Detect unused local file IDs to avoid an LLVM assertion
Each function's coverage metadata contains a *local file table* that maps local file IDs (used by the function's mapping regions) to global file IDs (shared by all functions in the same CGU).
LLVM requires all local file IDs to have at least one mapping region, and has an assertion that will fail if it detects a local file ID with no regions. To make sure that assertion doesn't fire, we need to detect and skip functions whose metadata would trigger it.
(This can't actually happen yet, because currently all of a function's spans must belong to the same file and expansion. But this will be an important edge case when adding expansion region support.)
|
|
this is more in line with the x86 parse error tests. The cross-platform tests were more complete anyway
|
|
add regression test for rust-lang#101650
closes #101650, which was already fixed.
|
|
fix autodiff macro on generic functions
heloo there!
This short PR allows applying the `autodiff` macro to generic functions like this one.
It only touches the frontend part, since the `rustc_autodiff` macro can already handle generics.
```rust
#[autodiff(d_square, Reverse, Duplicated, Active)]
fn square<T: std::ops::Mul<Output = T> + Copy>(x: &T) -> T {
*x * *x
}
```
Thanks to Manuel for creating an issue on this. For more information on this see #140032
r? `@ZuseZ4`
As always: thanks for any piece of feedback!!
Fixes: #140032
Tracking issue for autodiff: https://github.com/rust-lang/rust/issues/124509
|
|
gvn: avoid creating overlapping assignments
Quick fix #141038, as I couldn't find a way to avoid in-place modification. I'm considering handling all `ravlue` modifications within the `visit_statement` function.
r? mir-opt
|
|
name resolution for guard patterns
This PR provides an initial implementation of name resolution for guard patterns [(RFC 3637)](https://github.com/rust-lang/rfcs/blob/master/text/3637-guard-patterns.md). This does not change the requirement that the bindings on either side of an or-pattern must be the same [(proposal here)](https://github.com/rust-lang/rfcs/blob/master/text/3637-guard-patterns.md#allowing-mismatching-bindings-when-possible); the code that handles that is separate from what this PR touches, so I'm saving it for a follow-up.
On a technical level, this separates "collecting the bindings in a pattern" (which was already done for or-patterns) from "introducing those bindings into scope". I believe the approach used here can be extended straightforwardly in the future to work with `if let` guard patterns, but I haven't tried it myself since we don't allow those yet.
Tracking issue for guard patterns: #129967
cc ``@Nadrieril``
|
|
split `asm!` parsing and validation
This PR splits `asm!` parsing and validation into two separate steps.
The parser constructs a `Vec<RawAsmArg>`, with each element corresponding to an argument to one of the `asm!` macros.
The validation then checks things like ordering of arguments or that options are not provided twice.
The motivation is https://github.com/rust-lang/rust/issues/140279, which wants to add `#[cfg(...)]` support to these arguments. This support can now be added in a straightforward way by adding an `attributes: ast::AttrVec` field to `RawAsmArg`.
An extra reason for this split is that `rustfmt` probably wants to format the assembly at some point (currently that appears to be stubbed out, and the formatting is unstable https://github.com/rust-lang/style-team/issues/152).
r? ``@ghost`` (just want to look at CI for now)
cc ``@ytmimi`` we discussed asm formatting a little while ago in https://github.com/rust-lang/rustfmt/issues/6526. Am I correct in assuming that `AsmArgs` does not give enough information for formatting, but that `RawAsmArgs` would (it e.g. does not join information from multiple lines). This must have been an issue before?
try-job: aarch64-apple
|
|
Stabilize the avx512 target features
This PR stabilizes the AVX512 target features - see [this comment](https://github.com/rust-lang/rust/issues/111137#issuecomment-2745821279).
Tracking Issue - #44839
The target feature UI tests have been changed to `x87` (chosen because this is very unlikely to stablize ever, please comment if some other feature will be better)
related: #111137
|
|
|
|
|
|
|
|
|
|
Use `crate::` prefix for root macro suggestions
Fixes #141082
I've changed the prefix to `crate` directly, since it's compatible across all editions.
|
|
[win][arm64] Remove 'Arm64 Hazard' undocumented MSVC option and instead disable problematic test
PR #140758 added the undocumented `/arm64hazardfree` MSVC linker flag to work around a test failure where LLVM generated code that would trip a hazard in an outdated ARM processor.
Adding this flag caused issues with LLD, as it doesn't recognize it.
Rethinking the issue, using the undocumented flag seems like the incorrect solution: there's no guarantee that the flag won't be removed in the future, or change its meaning.
Instead, I've disabled the problematic test for Arm64 Windows and have filed a bug with the MSVC team to have the check removed: <https://developercommunity.microsoft.com/t/Remove-checking-for-and-fixing-Cortex-A/10905134>
This PR supersedes #140977
r? ```@jieyouxu```
|
|
Remove #![feature(let_chains)] from library and src/librustdoc
PR https://github.com/rust-lang/rust/pull/132833 has stabilized the `let_chains` feature. This PR removes the last occurences from the library, the compiler, and librustdoc (also because #140887 missed the conditional in one of the crates as it was behind the "rustc" feature).
We keep `core` as exercise for the future as updating it is non-trivial (see PR thread).
|
|
|
|
|
|
|
|
r=compiler-errors
check coroutines with `TypingMode::Borrowck` to avoid cyclic reasoning
MIR borrowck taints its output if an obligation fails. This could then cause `check_coroutine_obligations` to silence its error, causing us to not emit and actual error and ICE.
Fixes the ICE in https://github.com/rust-lang/trait-system-refactor-initiative/issues/199. It is unfortunately still a regression.
r? compiler-errors
|
|
Only select true errors in `impossible_predicates`
See description in test.
Fixes #141119
r? lcnr
|
|
Implement Display for ``rustc_target::callconv::Conv``
Follow up of https://github.com/rust-lang/rust/pull/133103#discussion_r1885552854
|
|
MIR borrowck taints its output if an obligation fails. This could then cause
`check_coroutine_obligations` to silence its error, causing us to not emit
and actual error and ICE.
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #140208 (Make well-formedness predicates no longer coinductive)
- #140957 (Add `#[must_use]` to Array::map)
- #141031 (Async drop fix for dropee from another crate (#140858))
- #141036 (ci: split the dist-ohos job)
- #141051 (Remove some unnecessary erases)
- #141056 (Lowercase git url for rust-lang/enzyme.git)
- #141059 (HIR: explain in comment why `ExprKind::If` "then" is an `Expr`)
- #141070 (Do not emit help when shorthand from macro when suggest `?` or `expect`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Do not emit help when shorthand from macro when suggest `?` or `expect`
Fixes #140659
I didn't fully minimize the original bug, but I found a similar test case, and they have perhaps the same root cause. For the bug mentioned in #140659 , I also tested it locally and passed it.
Jieyou has worked on this part before, maybe r? `@jieyouxu`
|
|
Async drop fix for dropee from another crate (#140858)
Fixes https://github.com/rust-lang/rust/issues/140858.
For `AsyncDestructor` impl def id was wrongly kept as a LocalDefId, which causes crash when dropee is declared in another crate.
Also, potential problem found:
when user crate drops type with async drop in dependency crate, and user crate doesn't enable `feature(async_drop)`, then sync drop version will be used.
Is it a problem? Do we need some notification about such situations?
|
|
Make well-formedness predicates no longer coinductive
This PR makes well-formedness no longer coinductive. It was made coinductive in https://github.com/rust-lang/rust/pull/98542, but AFAICT this was only to fix UI tests since we stopped lowering `where Ty:` to an empty-region outlives predicate but to a WF predicate instead.
Arguably it should lower to something completely different, something like a "type mentioned no-op predicate", but well-formedness serves this purpose fine today, and since no code (according to crater) relies on this coinductive behavior, we'd like to avoid having to emulate it in the new solver.
Fixes #123456 (I didn't want to add a test since it seems low-value to have a ICE test for a fuzzer minimization that is basically garbage code.)
Fixes #109764 (not sure if this behavior is emulatable w/o coinductive WF?)
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/169
r? lcnr
|
|
Revert "Fix linking statics on Arm64EC #140176"
This reverts PR #140176.
Unfortunately, this will reopen https://github.com/rust-lang/rust/issues/138541 (re-breaking the `arm64ec-pc-windows-msvc` target).
Unfortunately, multiple people are [reporting linker warnings related to `__rust_no_alloc_shim_is_unstable`](https://github.com/rust-lang/rust/pull/140176#issuecomment-2879715554) after this change in `x86_64-pc-windows-msvc` as well. The solution isn't quite clear yet, let's revert to avoid the linker warnings on the Tier 1 MSVC target for now[^timing], and try a reland with a determined solution for `__rust_no_alloc_shim_is_unstable`.
Judging from [people reporting that they are observing this also when bootstrapping w/ stage0 rustc](https://github.com/rust-lang/rust/pull/140176#issuecomment-2881867433), we may have to cut a new beta and then repoint stage0 against that newer beta?
cc `@dpaoliello` `@wesleywiser`
r? `@wesleywiser` (or compiler)
[^timing]: Note that it's still RustWeek this week, so most team members are N/A.
|
|
to it
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Rollup of 9 pull requests
Successful merges:
- #140791 (std: explain prefer `TryInto` over `TryFrom` when specifying traits bounds on generic function)
- #140834 (move (or remove) some impl Trait tests)
- #140910 (Remove `stable` attribute from wasi fs (read_exact|write_all)_at)
- #140984 (fix doc for UnixStream)
- #140997 (Add negative test coverage for `-Clink-self-contained` and `-Zlinker-features`)
- #141003 (Improve ternary operator recovery)
- #141009 (Migrate to modern datetime API)
- #141013 (Implement methods to set STARTUPINFO flags for Command API on Windows)
- #141026 (rustc-dev-guide subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Improve ternary operator recovery
This
- Improves the span of the error to not point at the next token
- Where possible, we use the span of the condition to further improve the span of the error to include the cond, and suggest a maybe-incorrect fix
Currently this works on free expressions, not let statements; some more refactoring would be needed to pass the span down, which I'm not sure is worth doing.
### Old
### New
|
|
Add negative test coverage for `-Clink-self-contained` and `-Zlinker-features`
Noticed while reviewing stabilization #140525 that we don't have any negative test coverage for these flags. Feel free to cherry-pick these tests into the stabilization PR, or we can land these before separately.
r? `@lqd`
|
|
move (or remove) some impl Trait tests
Probably not actually worth the effort, so I am stopping here :sweat_smile:
|
|
Remove manual WF hack
We do not need this hack anymore since we fixed the candidate selection problems with `Sized` bounds. We prefer built-in sized bounds now since #138176, which fixes the only regression this hack was intended to fix.
While this theoretically is broken for some code, for example, when there a param-env bound that shadows an impl or built-in trait, we don't see it in practice and IMO it's not worth the burden of having to maintain this wart in `compare_method_predicate_entailment`.
The code that regresses is, for example:
```rust
trait Bar<'a> {}
trait Foo<'a, T> {
fn method(&self)
where
Self: Bar<'a>;
}
struct W<'a, T>(&'a T)
where
Self: Bar<'a>;
impl<'a, 'b, T> Bar<'a> for W<'b, T> {}
impl<'a, 'b, T> Foo<'a, T> for W<'b, T> {
fn method(&self) {}
}
```
Specifically, I don't believe this is really going to be encountered in practice. For this to fail, there must be a where clause in the *trait method* that would shadow an impl or built-in (non-`Sized`) candidate in the trait, and this shadowing would need to be encountered when solving a nested WF goal from the impl self type.
See #108544 for the original regression. Crater run is clean!
r? lcnr
|
|
Rollup of 7 pull requests
Successful merges:
- #139749 (docs(library/core/src/pin): fix typo "necessarily" -> "necessary")
- #140685 (Simplify `Vec::as_non_null` implementation and make it `const`)
- #140712 (normalization: avoid incompletely constraining GAT args)
- #140768 (Improve `dangerous_implicit_aurorefs` diagnostic output)
- #140947 (Flush errors before deep normalize in `dropck_outlives`)
- #140990 (VxWorks: updates from recent libc versions)
- #141027 (remove `RustfmtState` to reduce `initial_rustfmt` complexity)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Flush errors before deep normalize in `dropck_outlives`
Deep normalization doesn't allow the ocx to have pending obligations, so process them before deeply normalizing.
Fixes https://github.com/rust-lang/rust/issues/140931
Fixes https://github.com/rust-lang/rust/issues/140462
|
|
Improve `dangerous_implicit_aurorefs` diagnostic output
This PR *greatly* improves the `dangerous_implicit_aurorefs` lint diagnostic output.
Kind of related to #140721.
r? ```@jieyouxu``` (maybe)
|
|
normalization: avoid incompletely constraining GAT args
We need to copy the behavior of #125214 in the new solver. This fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/202 which seems to be the cause of the regression in `deptypes`.
r? ```@compiler-errors```
|
|
Optimize `ToString` implementation for integers
Part of https://github.com/rust-lang/rust/issues/135543.
Follow-up of https://github.com/rust-lang/rust/pull/133247 and https://github.com/rust-lang/rust/pull/128204.
The benchmark results are:
| name| 1.87.0-nightly (3ea711f17 2025-03-09) | With this PR | diff |
|-|-|-|-|
| bench_i16 | 32.06 ns/iter (+/- 0.12) | 17.62 ns/iter (+/- 0.03) | -45% |
| bench_i32 | 31.61 ns/iter (+/- 0.04) | 15.10 ns/iter (+/- 0.06) | -52% |
| bench_i64 | 31.71 ns/iter (+/- 0.07) | 15.02 ns/iter (+/- 0.20) | -52% |
| bench_i8 | 13.21 ns/iter (+/- 0.14) | 14.93 ns/iter (+/- 0.16) | +13% |
| bench_u16 | 31.20 ns/iter (+/- 0.06) | 16.14 ns/iter (+/- 0.11) | -48% |
| bench_u32 | 33.27 ns/iter (+/- 0.05) | 16.18 ns/iter (+/- 0.10) | -51% |
| bench_u64 | 31.44 ns/iter (+/- 0.06) | 16.62 ns/iter (+/- 0.21) | -47% |
| bench_u8 | 10.57 ns/iter (+/- 0.30) | 13.00 ns/iter (+/- 0.43) | +22% |
More information about it in [the original comment](https://github.com/rust-lang/rust/pull/136264#discussion_r1987542954).
r? `@workingjubilee`
|
|
disable problematic test
|
|
Use the new solver in the `impossible_predicates`
The old solver is unsound for many reasons. One of which was weaponized by `@lcnr` in #140212, where the old solver was incompletely considering a dyn vtable method to be impossible and replacing its vtable entry with a null value. This null function could be called post-mono.
The new solver is expected to be less incomplete due to its correct handling of higher-ranked aliases in relate. This PR switches the `impossible_predicates` query to use the new solver, which patches this UB.
r? lcnr
|
|
|
