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
remove `RustfmtState` to reduce `initial_rustfmt` complexity
The current use of `RustfmtState` doesn't serve its main purpose as it never does the lazy evaulation since `Build::build` forces it to be ready on the early stage. If we want rustfmt to be ready on the early stage, we don't need to have `RustfmtState` complexity at all.
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)
docs(library/core/src/pin): fix typo "necessarily" -> "necessary"
Fix a typo in [`library/core/src/pin.rs`](14662fabeb/library/core/src/pin.rs), from
> As we'll see later, this is **necessarily** from the time the value is first pinned until the end of its lifespan.
to
> As we'll see later, this is **necessary** from the time the value is first pinned until the end of its lifespan.
(my emphasis).
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
Rollup of 7 pull requests
Successful merges:
- #140827 (Do not ICE when reassigning in GatherLocalsVisitor on the bad path)
- #140904 (Add an issue template for future-incompatible lints)
- #140953 (Fix a compiletest blessing message)
- #140973 (Update rustix to 1.0.7 for bootstrap)
- #140976 (Add `Ipv4Addr` and `Ipv6Addr` diagnostic items)
- #140988 (MaybeUninit::write: fix doc)
- #140989 (Suggest replace f with f: Box<f> when expr field is short hand)
r? `@ghost`
`@rustbot` modify labels: rollup
The current use of `RustfmtState` doesn't serve its main purpose as it
never does the lazy evaulation since `Build::build` forces it to be ready
on the early stage. If we want rustfmt to be ready on the early stage, we
don't need to have `RustfmtState` complexity at all.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Temporarily use Windows Server 2022 instead of Windows Server 2025 images
Tracking issue: https://github.com/rust-lang/rust/issues/141022
At the moment, it seems like Windows Server 2025 20250504.1.0 is misconfigured, causing insufficient disk space failures. Temporarily go back to Windows Server 2022 in the hope that those are not also misconfigured to try to unblock the queue.
r? `@marcoieni` (or infra-ci)
At the moment, it seems like Windows Server 2025 20250504.1.0 is
misconfigured causing insufficient disk space failures. Temporarily go
back to Windows Server 2022 in the hope that those are not also
misconfigured.
MaybeUninit::write: fix doc
# Fix doc for `MaybeUninit::write`
The documentation refers to the way `MaybeUninit` stores data internally. The property of not dropping content on context exit is the responsibility of `ManuallyDrop`.
Add an issue template for future-incompatible lints
This adds a GitHub issue template for future-incompatible lints. Most of the existing tracking issues have been using different formats with different information, and I think it would be helpful to make them a little more consistent and to ensure that sufficient information is provided.
Some comments on my choices:
* Added a dedicated section to describe *why* the change is being made. Many existing issues already have this, so let's standardize on it.
* Have a section with a very clear example. Almost all of the existing issues have this in one form or another.
* Added a "Recommendations" section, since this is something I see missing in several of the existing issues, and this is really important information IMHO.
* I reworded the "When" section. The existing template mentioned that these get reviewed every 6 weeks which my understanding is not true. That's also not very helpful information to the user, since it doesn't really answer the question. I'm not sure this section will actually be useful since I suspect most of the time we don't know when it will change (there have been a few exceptions).
* Clearly show the expected progression steps. Several issues already have this.
* Added implementation history, which is useful for linking PRs. (IDK, this could get merged with "Steps".)
Stage0 bootstrap update
This PR [follows the release process](https://forge.rust-lang.org/release/process.html#master-bootstrap-update-tuesday) to update the stage0 compiler.
The only thing of note is 58651d1b31, which was flagged by clippy as a correctness fix. I think allowing that lint in our case makes sense, but it's worth to have a second pair of eyes on it.
r? `@Mark-Simulacrum`
Do not remove `super` keyword from `super let`
This is affecting a macro in the standard library:
bc7512ee63/library/core/src/pin.rs (L1945)
I added an exception in 6f6a9a585891d0a2d1114a7a621f35f28f39c0d9, but I'd like to remove it eventually, so opening this in-tree to not block this on the next rustfmt sync.
r? `@calebcartwright` or `@ytmimi`
cg_llvm: Clean up some inline assembly bindings
This PR combines a few loosely-related cleanups to LLVM bindings related to inline assembly. These include:
- Replacing `LLVMRustInlineAsm` with LLVM-C's `LLVMGetInlineAsm`
- Adjusting FFI declarations to avoid the need for explicit `as_c_char_ptr` conversions
- Flattening control flow in `inline_asm_call`
There should be no functional changes.
ui/async-drop-initial: factor in panic strategy in destructor size check
the size of `AsyncStruct`'s destructor depends on whether the configured panic strategy is 'unwind' or 'abort' so factor that into the test using conditional compilation
fixesrust-lang/rust#140939fixesrust-lang/rust#140493
