Fix `ElaborateBoxDerefs` on debug varinfo
Slightly simplifies the `ElaborateBoxDerefs` pass to fix cases where it was applying the wrong projections to debug var infos containing places that deref boxes.
From what I can tell[^1], we don't actually have any tests (or code anywhere, really) that exercise `debug x => *(...: Box<T>)`, and it's very difficult to trigger this in surface Rust, so I wrote a custom MIR test.
What happens is that the pass was turning `*(SOME_PLACE: Box<T>)` into `*(*((((SOME_PLACE).0: Unique<T>).0: NonNull<T>).0: *const T))` in debug var infos. In particular, notice the *double deref*, which was wrong.
This is the root cause of #128554, so this PR fixes#128554 as well. The reason that async closures was affected is because of the way that we compute the [`ByMove` body](https://github.com/rust-lang/rust/blob/master/compiler/rustc_mir_transform/src/coroutine/by_move_body.rs), which resulted in `*(...: Box<T>)` in debug var info. But this really has nothing to do with async closures.
[^1]: Validated by literally replacing the `if elem == PlaceElem::Deref && base_ty.is_box() { ... }` innards with a `panic!()`, which compiled all of stage2 without panicking.
[rustdoc] Stop showing impl items for negative impls
Fixes https://github.com/rust-lang/rust/issues/128799.
As discussed with `@fmease,` they have a broader patch in progress, so this (small) PR will at least allow for them to have a regression test. :)
r? `@fmease`
Differentiate between methods and associated functions in diagnostics
Accurately refer to assoc fn without receiver as assoc fn instead of methods. Add `AssocItem::descr` method to centralize where we call methods and associated functions.
run-make: explaing why fmt-write-bloat is ignore-windows
The trouble here is that libc doesn't exist on Windows. Well it kinda does but it isn't called that so we substitute a name that works. Ideally finding necessary libs for the platform would be done at a higher level but until then this should work.
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: i686-mingw
WF-check struct field types at construction site
Fixes#126272.
Fixes#127299.
Rustc of course already WF-checked the field types at the definition
site, but for error tainting of consts to work properly, there needs to
be an error emitted at the use site. Previously, with no use-site error,
we proceeded with CTFE and ran into ICEs since we are running code with
type errors.
Emitting use-site errors also brings struct-like constructors more in
line with fn-like constructors since they already emit use-site errors
for WF issues.
r? `@BoxyUwU`
Accurately refer to assoc fn without receiver as assoc fn instead of methods.
Add `AssocItem::descr` method to centralize where we call methods and associated functions.
Enable zstd for debug compression.
Set LLVM_ENABLE_ZSTD alongside LLVM_ENABLE_ZLIB so that --compress-debug-sections=zstd is an option.
See #120953
try-job: x86_64-gnu-tools
Ensure let stmt compound assignment removal suggestion respect codepoint boundaries
Previously we would try to issue a suggestion for `let x <op>= 1`, i.e.
a compound assignment within a `let` binding, to remove the `<op>`. The
suggestion code unfortunately incorrectly assumed that the `<op>` is an
exactly-1-byte ASCII character, but this assumption is incorrect because
we also recover Unicode-confusables like `➖=` as `-=`. In this example,
the suggestion code used a `+ BytePos(1)` to calculate the span of the
`<op>` codepoint that looks like `-` but the mult-byte Unicode
look-alike would cause the suggested removal span to be inside a
multi-byte codepoint boundary, triggering a codepoint boundary
assertion.
The fix is to use `SourceMap::start_point(token_span)` which properly accounts for codepoint boundaries.
Fixes#128845.
cc #128790
r? ````@fmease````
Use `SourceMap::end_point` instead of `- BytePos(1)` in arg removal suggestion
Previously, we tried to remove extra arg commas when providing extra arg removal suggestions. One of
the edge cases is having to account for an arg that has a closing delimiter `)` following it.
However, the previous suggestion code assumed that the delimiter is in fact exactly the 1-byte `)`
character. This assumption was proven incorrect, because we recover from Unicode-confusable
delimiters in the parser, which means that the ending delimiter could be a multi-byte codepoint
that looks *like* a `)`. Subtracing 1 byte could land us in the middle of a codepoint, triggering a
codepoint boundary assertion.
This is fixed by using `SourceMap::end_point` which properly accounts for codepoint boundaries.
Fixes#128717.
cc ````@fmease```` and #128790
Miscellaneous improvements to struct tail normalization
1. Make checks for foreign tails more accurate by normalizing the struct tail. I didn't write a test for this one.
2. Normalize when computing struct tail for `offset_of` for slice/str. This fixes the new solver only.
3. Normalizing when computing tails for disaligned reference check. This fixes both solvers.
r? lcnr
For codepoint boundary assertion triggered by a let stmt compound
assignment removal suggestion when encountering recovered multi-byte
compound ops.
Issue: <https://github.com/rust-lang/rust/issues/128845>
run-make: enable msvc for staticlib-dylib-linkage
`-Zstaticlib-allow-rdylib-deps` on MSVC returns things like `/LIBPATH:R:\rust\build\x86_64-pc-windows-msvc\test\run-make\staticlib-dylib-linkage\rmake_out`. That is a linker argument rather than a `cc` argument. Which makes sense because rustc interacts directly with the linker on MSVC targets. So we need to tell the C compiler to pass on the arguments to the linker.
try-job: x86_64-msvc
try-job: i686-msvc
run-make: enable msvc for redundant-libs
The issue here was that `foo` was not exporting any functions therefore creating an import library was unnecessary and elided by the linker.
I fixed it by exporting the functions.
try-job: x86_64-msvc
try-job: i686-msvc
Don't inline tainted MIR bodies
Don't inline MIR bodies that are tainted, since they're not necessarily well-formed.
Fixes#128601 (I didn't add a new test, just copied one from the crashes, since they're the same root cause).
Fixes#122909.
Don't implement `AsyncFn` for `FnDef`/`FnPtr` that wouldnt implement `Fn`
Due to unsafety, ABI, or the presence of target features, some `FnDef`/`FnPtr` types don't implement `Fn*`. Do the same for `AsyncFn*`.
Noticed this due to #128764, but this isn't really related to that ICE, which is fixed in #128792.
Make `validate_mir` ensure the final MIR for all bodies
A lot of the crashes tests use `-Zpolymorphize` or `-Zdump-mir` for their side effect of computing the `optimized_mir` for all bodies, which will uncover bugs with late MIR passes like the inliner. I don't like having all these tests depend on `-Zpolymorphize` (or other hacky ways) for no reason, so this PR extends the `-Zvalidate-mir` flag to ensure `optimized_mir`/`mir_for_ctfe` for all body owners during the analysis phase.
Two thoughts:
1. This could be moved later in the compilation pipeline I guess? I don't really think it matters, though.
1. This could alternatively be expressed using a new flag, though I don't necessarily see much value in separating these.
For example, #128171 could have used this flag, in the `tests/ui/polymorphization/inline-incorrect-early-bound.rs`.
r? mir
Add tracking issue to core-pattern-type
While the actual `pattern_types` feature flag has an issue assigned, the exported macro and its module do not.
cc #123646
