| Age | Commit message (Collapse) | Author | Lines |
|
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).
|
|
move expensive layout sanity check to debug assertions
It is [hard to fix](https://github.com/rust-lang/rust/issues/141006#issuecomment-2883415000) the slowness in the uninhabitedness computation for very big types but we can fix the very specific case of them being called during the layout sanity checks, as described in #140944.
So this PR moves this uninhabitedness check to the other expensive layout sanity checks that are ran under `debug_assertions`.
It makes building the `lemmy_api_routes` crate's self-profile `layout_of` query go from
```
+--------------------------------------------------------+-----------+-----------------+----------+------------+---------------------------------+
| Item | Self time | % of total time | Time | Item count | Incremental result hashing time |
+--------------------------------------------------------+-----------+-----------------+----------+------------+---------------------------------+
| layout_of | 63.02s | 41.895 | 244.26s | 123703 | 50.30ms |
+--------------------------------------------------------+-----------+-----------------+----------+------------+---------------------------------+
```
on master (2m17s total), to
```
| layout_of | 330.21ms | 0.372 | 26.90s | 123703 | 53.19ms |
```
with this PR (1m15s total).
(Note that the [perf run results](https://github.com/rust-lang/rust/pull/141039#issuecomment-2884688756) below look a bit better than [an earlier run](https://perf.rust-lang.org/compare.html?start=4eca99a18eab3d4e28ed1ce3ee620d442955a470&end=c4a00993f8ee02c7565e7be652608817ea2fb97d&stat=instructions:u) I did in another PR. There may be some positive noise there, or post-merge results could differ a bit)
Since we discussed this today, r? `@compiler-errors` — and cc `@lcnr` and `@RalfJung.`
|
|
Merge mir query analysis invocations
r? `@ghost`
same thing as https://github.com/rust-lang/rust/pull/140854 just a different set of queries
Doing this in general has some bad cache coherence issues because the query caches are laid out in Vec<QueryResult> lists per query where each index refers to a DefId in the same order as we're iterating. Iterating two or more lists at the same time does have cache issues, so I want to poke a bit at it to see if we can't merge just a few of them at a time.
|
|
|
|
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
|
|
Enable rust-analyzer to go from query definition to the corresponding provider field
r? `@compiler-errors`
|
|
turn lld warning on old gccs into info log
As discussed in #140964 and IRL, this PR switches the spammy warning shown unconditionally when an old gcc doesn't support `-fuse-ld=lld` and we retry linking without it, to an info debug log so we don't lose it.
r? `@Mark-Simulacrum`
Fixes #140964
|
|
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.
|
|
|
|
provider field
|
|
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`
|
|
HIR: explain in comment why `ExprKind::If` "then" is an `Expr`
One could be tempted to replace the "then" `hir::Expr` with kind `hir::ExprKind::Block` by a `hir::Block`. Explain why this would not be a good idea.
I've been there.
r? ``@compiler-errors``
|
|
Remove some unnecessary erases
Some nits I pulled out of https://github.com/rust-lang/rust/pull/140814.
|
|
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.
|
|
r=GuillaumeGomez
Subtree update GCC backend 2025 05 14
cc `@antoyo`
|
|
trait_sel: deep reject `match_normalize_trait_ref`
Spotted during an in-person review of #137944 at RustWeek: `match_normalize_trait_ref` could be using `DeepRejectCtxt` to exit early as an optimisation for projection candidates, like is done with param candidates.
r? `@lcnr`
cc `@oli-obk`
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
Invoke a query only when it doesn't return immediately anyway
This should cause less query key caching and less dep graph data, hopefully resulting in some perf improvements
|
|
Clippy subtree update
r? `@Manishearth`
Cargo.lock update due to Clippy version bump.
|
|
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

|
|
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
|
|
One could be tempted to replace the "then" `hir::Expr` with kind
`hir::ExprKind::Block` by a `hir::Block`. Explain why this would not be
a good idea.
|
|
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```
|
|
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
|
|
|
|
|
|
Unfortunately, multiple people are reporting linker warnings related to
`__rust_no_alloc_shim_is_unstable` after this change. The solution isn't
quite clear yet, let's revert to green for now, and try a reland with a
determined solution for `__rust_no_alloc_shim_is_unstable`.
This reverts commit c8b7f32434c0306db5c1b974ee43443746098a92, reversing
changes made to 667247db71ea18c4130dd018d060e7f09d589490.
|
|
|
|
|
|
|
|
Suggest replace f with f: Box<f> when expr field is short hand
Fixes #139631
r? compiler
|
|
Add `Ipv4Addr` and `Ipv6Addr` diagnostic items
They will be used in Clippy to detect runtime parsing of known-valid IP addresses.
|
|
Do not ICE when reassigning in GatherLocalsVisitor on the bad path
Fixes https://github.com/rust-lang/rust/issues/140785
Fixes https://github.com/rust-lang/rust/issues/140730
See comment in code.
r? oli-obk
|
|
|
|
|
|
subtree-update_cg_gcc_2025-05-14
|
|
The reasons I'm doing it is that
* merging those blocks allows for more parallelism as you don't run parallel blocks in sequence
* merging blocks allows merging analysis queries shrinking the dep graph
* should allow us to do more early aborting in case of errors and/or moving query calls from the analysis query into others that allow early aborting the others (and doing more tainting and stuff)
|