| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 8 pull requests
Successful merges:
- #128273 (Improve `Ord` violation help)
- #128807 (run-make: explaing why fmt-write-bloat is ignore-windows)
- #128903 (rustdoc-json-types `Discriminant`: fix typo)
- #128905 (gitignore: Add Zed and Helix editors)
- #128908 (diagnostics: do not warn when a lifetime bound infers itself)
- #128909 (Fix dump-ice-to-disk for RUSTC_ICE=0 users)
- #128910 (Differentiate between methods and associated functions in diagnostics)
- #128923 ([rustdoc] Stop showing impl items for negative impls)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
[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.
|
|
Fix dump-ice-to-disk for RUSTC_ICE=0 users
Before this change, the test fails if you run it with `RUSTC_ICE=0`.
|
|
r=compiler-errors
diagnostics: do not warn when a lifetime bound infers itself
Fixes #119228
|
|
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`
|
|
Add a set of tests for LLVM 19
Close #107681. Close #118306. Close #126585.
r? compiler
|
|
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
|
|
r=GuillaumeGomez
rustdoc: do not run doctests with invalid langstrings
https://github.com/rust-lang/rust/pull/124577#issuecomment-2276034737
CC ``@decathorpe``
|
|
|
|
|
|
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>
|
|
assertion
Issue: <https://github.com/rust-lang/rust/issues/128717>
|
|
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.
|
|
|
|
rustdoc-json: add a test for impls on private & hidden types
Fixes #107278 (or rather just ensures it won't resurface)
r? ``@aDotInTheVoid``
|
|
rustdoc: strip unreachable modules
Modules are now stripped based on the same logic that's used to strip other item kinds
Fixes #101105
|
|
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.
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #128306 (Update NonNull::align_offset quarantees)
- #128612 (Make `validate_mir` ensure the final MIR for all bodies)
- #128648 (Add regression test)
- #128749 (Mark `{f32,f64}::{next_up,next_down,midpoint}` inline)
- #128795 (Update E0517 message to reflect RFC 2195.)
- #128825 (rm `declared_features` field in resolver)
- #128826 (Only suggest `#[allow]` for `--warn` and `--deny` lint level flags)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Only suggest `#[allow]` for `--warn` and `--deny` lint level flags
`--force-warn` and `--forbid` cannot be overridden
|
|
Add regression test
Fixes #125873
|
|
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
|
|
|
|
modules are now stripped based on the same logic that's used to strip other item kinds
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
Add -Zmetrics-dir=PATH to save diagnostic metadata to disk
r? ``@estebank``
|
