Remove some dead code for dumping MIR for a single DefId
The functions that call `dump_mir_def_ids` are themselves never called with a specific DefId; they always dump MIR for the entire crate.
remove allows_weak_linkage target spec flag
The flag doesn't actually do anything. I have no idea what it's original purpose was.
It got introduced in https://github.com/rust-lang/rust/commit/59cfe904dcfbe2c3ad5396131b3d3ba6b7179fdd, but already a few months later in https://github.com/rust-lang/rust/commit/57950982b27c6ab45509c1f2db4a01fa1d2cfebb both of its uses were removed when the entire file `src/librustc_trans/closure.rs` got deleted.
It seems like back in the day we used weak linkage for closures by default and MinGW wasn't happy about that? But not much later the way we compile closures got changed, making the work-around unnecessary. The flag has then persisted unused for 10 years. A couple of Windows/UEFI targets are setting `allows_weak_linkage: false` but I assume that was just cargo-culted.
But to be sure, let's ping the folks listed for the affected targets and other Windows folks:
@dvdhrm @nicholasbishop @Berrysoft @mati865 @thomcc @tbu- @ChrisDenton
resolve: Module-related refactorings
Extracted parts of https://github.com/rust-lang/rust/pull/156362 that don't require splitting `(Local,Extern)ModuleData` into separate data structures.
- Some `expect_local` assertions are added
- Methods that need to exist on all of `Module` and `(Local,Extern)Module` are implemented for `ModuleData`
- Methods that need to exist on `ModuleKind` are moved to `ModuleKind`
- Some unnecessary complicated logic using `graph_root` is simplified
- `glob_importers` are filled and used only for local modules.
- Some unnecessary logic is skipped for extern modules in `resolve_ident_in_module_non_globs_unadjusted`
- Module construction functions are cleaned up
- `module_to_string` is simplified
r? @nnethercote
Add `Drop::pin_drop` for pinned drops
This PR is part of the `pin_ergonomics` experiment (the tracking issue is rust-lang/rust#130494). It allows implementing `Drop` with a pinned `self` receiver, which is required for safe pin-projection.
Implementations:
- [x] At least and at most one of `drop` and `pin_drop` should be implemented.
- [x] No direct call of `drop` or `pin_drop`. They should only be called by the drop glue.
- [x] `pin_drop` must and must only be used with types that support pin-projection (i.e. types with `#[pin_v2]`).
- [ ] Allows writing `fn drop(&pin mut self)` and desugars to `fn pin_drop(&pin mut self)`. (Will be in the next PRs)
error on empty `export_name`
fixes https://github.com/rust-lang/rust/issues/155495
Using an empty string as the name makes LLVM make up a name. However this name can be inconsistent between compilation units, which is UB and can cause linking errors, and some parts of LLVM just crash on the empty name (see the linked issue).
As far as we know there is only one valid pattern that could use this, a `#[used]` static that is not referenced by the program at all. That is not UB, but the `export_name` is not required for that to work, just normal rust name mangling would do fine.
Technically this is a breaking change, but it seems unlikely that this actually breaks code in the wild that wasn't already broken. I'll leave it up to T-lang to determine what is required here (crater run, FCW, ...), but my gut feeling is that we could just merge this and nobody would notice.
Change `SwitchInt` handling in dataflow analysis.
We call `get_switch_int_data` once for the switch and then pass that data to `apply_switch_int_edge_effect` for each switch target.
The only case in practice is `MaybePlacesSwitchIntData` which does an awkward thing, maintaining an index into the discriminants and updating it on each call to `apply_switch_int_edge_effect`.
This commit changes things to do more work up front in `get_switch_int_data`, in order to then do less work in `apply_switch_int_edge_effect`. This avoids the need for the `variants` and `next_discr` methods and the discriminants index. Overall it's a little simpler.
r? @cjgillot
Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint
This is an extension to rust-lang/rust#147382.
With this PR `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` considered as must use iif `T` must be used.
For such cases the lint will mention that `T` is wrapped in a `Result`/`ControlFlow` with an uninhabited error/break.
The reasoning here is that `Result<T, Uninhabited>` is equivalent to `T` in which values can be represented and thus the must-used-ness should also be equivalent.
Fixes https://github.com/rust-lang/rust/issues/65861
fix: Guard SizeSkeleton::compute against stack overflow
Fixesrust-lang/rust#156137
Fix: extract the recursion into a private `compute_inner` that carries a depth counter. When depth exceeds the crate's recursion limit, return `LayoutError::Unknown` and let the existing transmute size-check produce a normal error instead of crashing.
A regression test is included in `tests/ui/transmute/`.
Avoid invalid spans in dotdotdot rest pattern suggestions
Fixesrust-lang/rust#156316
The parser recovers Unicode confusables such as `···` as `...`, while keeping the original source span over the multibyte characters.
`recover_dotdotdot_rest_pat` built its suggestion by subtracting `BytePos(1)` from the end of that recovered token span. For multibyte characters, that can create a span boundary inside a UTF-8, causing diagnostic emission to ICE.
This changes the suggestion to replace the whole recovered token span with `..` instead of slicing off one byte.
fix incorrect suggestions in private import diagnostic
Resolvesrust-lang/rust#156060.
1. In nested imports like `use two::{One, ...}`, the diagnostic suggested replacing the `One` with a multi-segment path of a different module, producing invalid code like `use crate::two::{one::One, Two}`. Skip it when `single_nested == true`.
2. Stop unconditionally skipping the first segment of `import.module_path`, which can produce incorrect paths in edition 2018 and later.
3. Mark the suggestion as "directly" instead of "through the re-export" when the import's source is the definition itself.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#156246 (Introduce a `RerunNonErased` error type mirroring `NoSolution`, to better track when we're bailing)
- rust-lang/rust#156038 (turn `compute_goal_fast_path` into a single match)
- rust-lang/rust#156291 (Treat MSVC "performing full link" message as informational)
- rust-lang/rust#156301 (Avoid ICE when suggesting as_ref for ill-typed closure receivers)
Avoid ICE when suggesting as_ref for ill-typed closure receivers
Fixesrust-lang/rust#156299
When building mismatch suggestions, `can_use_as_ref` may inspect the receiver of a method call that is itself an ill-typed closure expression. In that recovery path, the receiver may not have a recorded type in `TypeckResults`.
Use `expr_ty_opt` instead of `expr_ty` so the optional `as_ref()` suggestion is skipped when the receiver type is unavailable.
Treat MSVC "performing full link" message as informational
When the MSVC incremental linker finds a .ilk file for incremental linking but its associated .exe file is missing, this message is printed to stdout:
```text
LINK : ...\foo.exe not found or not build by the last incremental link; performing full link
```
However, if both the .ilk and .exe files are missing (for a clean build), the message isn't printed and it still does a full link. So, the presence of the message doesn't affect the result of the build.
See rust-lang/rust#156209 for further context.
r? @mati865
cc @jyn514
Do not cache `lints_that_dont_need_to_run` across sessions
The `lints_that_dont_need_to_run` query depends on the lint store (which includes internal lints under `-Zunstable-options`). Because that flag is deliberately not part of the incremental command-line hash, incremental builds could load stale results from sessions with a different lint configuration, leading to an ICE.
This PR marks the query `eval_always` so it is recomputed for the current session instead of being loaded from cache.
Fixesrust-lang/rust#156182.