| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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
|
|
rustc_on_unimplemented
|
|
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.
|
|
For aarch64-apple and aarch64-windows, platform docs state that code
must use frame pointers correctly. This is because the AAPCS64 mandates
that a platform specify its frame pointer conformance requirements:
- Apple: https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Respect-the-purpose-of-specific-CPU-registers
- Windows: https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers
- AAPCS64: https://github.com/ARM-software/abi-aa/blob/4492d1570eb70c8fd146623e0db65b2d241f12e7/aapcs64/aapcs64.rst#the-frame-pointer
Unwinding code either requires unwind tables or frame pointers, and
on aarch64 the expectation is that one can use frame pointers for this.
Most Linux targets represent a motley variety of possible distributions,
so it is unclear who to defer to on conformance, other than perhaps Arm.
In the absence of a specific edict for a given aarch64-linux target,
Rust will assume aarch64-linux targets use non-leaf frame pointers.
This reflects what compilers like clang do.
|
|
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
|
|
|
|
Co-authored-by: Ookiineko <chiisaineko@protonmail.com>
|
|
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)
|
