| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#144397 (`tests/ui/issues/`: The Issues Strike Back [2/N])
- rust-lang/rust#144410 (Make tier 3 musl targets link dynamically by default)
- rust-lang/rust#144708 (Add tracing to step.rs and friends)
- rust-lang/rust#144730 (Create a typed wrapper for codegen backends in bootstrap)
- rust-lang/rust#144771 (Remove some noisy triagebot pings for myself)
- rust-lang/rust#144772 (add unsupported_calling_conventions to lint list)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
`tests/ui/issues/`: The Issues Strike Back [2/N]
Some `tests/ui/issues/` housekeeping, to trim down number of tests directly under `tests/ui/issues/`. Part of https://github.com/rust-lang/rust/issues/133895.
r? ``@jieyouxu``
|
|
r=GuillaumeGomez
rustdoc-json: Move `#[macro_export]` from `Other` to it's own variant
Followup to rust-lang/rust#142936.
cargo-semver-checks [cares about this attribute](https://github.com/obi1kenobi/trustfall-rustdoc-adapter/blob/4a0d1b0ca19b3115bb65d0b6695c388d7f474ac9/src/visibility_tracker.rs#L459-L476), and it wasn't included in the initial PR for structured attributes CC `@obi1kenobi.`
r? `@GuillaumeGomez`
|
|
Extend `is_case_difference` to handle digit-letter confusables
This PR extends `is_case_difference` to handle digit-letter confusables
Add support for detecting 0/O, 1/l, 5/S, 8/B, 9/g confusables in error suggestions.
r? `@estebank`
|
|
r=GuillaumeGomez
rustdoc: never link to unnamable items
fixes rust-lang/rust#143222
|
|
|
|
fix: Match width of ascii and unicode secondary file start
The current [unicode secondary file start](https://github.com/rust-lang/rust/blob/64ca23b6235732fa61c0a2b957c5d7e591e7c972/compiler/rustc_errors/src/emitter.rs#L2991) is only three characters, whereas the ASCII variant and normal [file start](https://github.com/rust-lang/rust/blob/64ca23b6235732fa61c0a2b957c5d7e591e7c972/compiler/rustc_errors/src/emitter.rs#L2983-L2984) are four characters. This slight difference caused the paths following a Unicode secondary file start to not align with other structured elements.
|
|
Consider operator's span when computing binop expr span
When computing the span of a binop consisting of `lhs` and `rhs`, we previously just took the spans of `lhs.span.to(rhs.span)`. In the case that both `lhs` and `rhs` are both arguments to a macro, this can produce a wildly incorrect span.
To fix this, first compute the span between `lhs` and the binary operator, which will cause `lhs` to possibly be adjusted to a relevant macro metavar, and then compute that span extended to `rhs`, which will cause it to also be adjusted to a relevant macro metavar.
This coincidentally fixes a FIXME in `tests/ui/lint/wide_pointer_comparisons.rs` and suppresses a nonsense suggestion.
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#136840 (Fix linker-plugin-lto only doing thin lto)
- rust-lang/rust#144053 (Remove install Rust script from CI)
- rust-lang/rust#144297 (Make `libtest::ERROR_EXIT_CODE` const public to not redefine it in rustdoc)
- rust-lang/rust#144721 (`std_detect`: Linux 6.16 support for RISC-V)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix linker-plugin-lto only doing thin lto
When rust provides LLVM bitcode files to lld and the bitcode contains
function summaries as used for thin lto, lld defaults to using thin lto.
This prevents some optimizations that are only applied for fat lto.
We solve this by not creating function summaries when fat lto is
enabled. The bitcode for the module is just directly written out.
An alternative solution would be to set the `ThinLTO=0` module flag to
signal lld to do fat lto.
The code in clang that sets this flag is here:
https://github.com/llvm/llvm-project/blob/560149b5e3c891c64899e9912e29467a69dc3a4c/clang/lib/CodeGen/BackendUtil.cpp#L1150
The code in LLVM that queries the flag and defaults to thin lto if not
set is here:
https://github.com/llvm/llvm-project/blob/e258bca9505f35e0a22cb213a305eea9b76d11ea/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp#L4441-L4446
try-job: x86_64-gnu-debug
try-job: aarch64-gnu-debug
|
|
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#144657 (fix: Only "close the window" when its the last annotated file)
- rust-lang/rust#144665 (Re-block SRoA on SIMD types)
- rust-lang/rust#144713 (`rustc_middle::ty` cleanups)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Re-block SRoA on SIMD types
Fixes rust-lang/rust#144621
|
|
fix: Only "close the window" when its the last annotated file
While comparing the Unicode theme output of `rustc` and `annotate-snippets`, I found that `rustc` would ["close the window"](https://github.com/rust-lang/rust/blob/686bc1c5f9c06762b18082434c04d514acf6707e/compiler/rustc_errors/src/emitter.rs#L1025-L1027) (draw a `╰╴`), even though there were other annotated files that followed the current one. This PR makes it so the emitter will only "close the window" on the last annotated file.
Before:
```
error[E0624]: method `method` is private
╭▸ $DIR/close_window.rs:9:7
│
LL │ s.method();
╰╴ ━━━━━━ private method
│
⸬ $DIR/auxiliary/close_window.rs:3:5
│
LL │ fn method(&self) {}
╰╴ ──────────────── private method defined here
```
After:
```
error[E0624]: method `method` is private
╭▸ $DIR/close_window.rs:9:7
│
LL │ s.method();
│ ━━━━━━ private method
│
⸬ $DIR/auxiliary/close_window.rs:3:5
│
LL │ fn method(&self) {}
╰╴ ──────────────── private method defined here
```
|
|
When rust provides LLVM bitcode files to lld and the bitcode contains
function summaries as used for thin lto, lld defaults to using thin lto.
This prevents some optimizations that are only applied for fat lto.
We solve this by not creating function summaries when fat lto is
enabled. The bitcode for the module is just directly written out.
An alternative solution would be to set the `ThinLTO=0` module flag to
signal lld to do fat lto.
The code in clang that sets this flag is here:
https://github.com/llvm/llvm-project/blob/560149b5e3c891c64899e9912e29467a69dc3a4c/clang/lib/CodeGen/BackendUtil.cpp#L1150
The code in LLVM that queries the flag and defaults to thin lto if not
set is here:
https://github.com/llvm/llvm-project/blob/e258bca9505f35e0a22cb213a305eea9b76d11ea/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp#L4441-L4446
|
|
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
coverage: Re-land "Enlarge empty spans during MIR instrumentation"
This allows us to assume that coverage spans will only be discarded during codegen in very unusual situations.
---
This seemingly-simple change has a rather messy history:
- rust-lang/rust#140847
- rust-lang/rust#141650
- rust-lang/rust#144298
- rust-lang/rust#144480
Since then, a number of related changes have landed that should make it reasonable to try again:
- rust-lang/rust#144530
- rust-lang/rust#144560
- rust-lang/rust#144616
In particular, we have multiple fixes/mitigations, and a confirmed regression test for the original bug that is not triggered by re-landing the changes in this PR.
|
|
Implement support for `become` and explicit tail call codegen for the LLVM backend
This PR implements codegen of explicit tail calls via `become` in `rustc_codegen_ssa` and support within the LLVM backend. Completes a task on (https://github.com/rust-lang/rust/issues/112788). This PR implements all the necessary bits to make explicit tail calls usable, other backends have received stubs for now and will ICE if you use `become` on them. I suspect there is some bikeshedding to be done on how we should go about implementing this for other backends, but it should be relatively straightforward for GCC after this is merged.
During development I also put together a POC bytecode VM based on tail call dispatch to test these changes out and analyze the codegen to make sure it generates expected assembly. That is available [here](https://github.com/xacrimon/tcvm).
|
|
Fix Box allocator drop elaboration
New version of rust-lang/rust#131146.
Clearing Box's drop flag after running its destructor can cause it to skip dropping its allocator, so just don't. Its cleared by the drop ladder code afterwards already.
Unlike the last PR this also handles other types with destructors properly, in the event that we can have open drops on them in the future (by partial initialization or DerefMove or something).
Finally, I also added tests for the interaction with async drop here but I discovered rust-lang/rust#143658, so one of the tests has a `knownbug` annotation. Not sure if it should be in this PR at all though.
Fixes rust-lang/rust#131082
r? wesleywiser - prev. reviewer
|
|
|
|
uniquify root goals during HIR typeck
We need to rely on region identity to deal with hangs such as https://github.com/rust-lang/trait-system-refactor-initiative/issues/210 and to keep the current behavior of `fn try_merge_responses`.
This is a problem as borrowck starts by replacing each *occurrence* of a region with a unique inference variable. This frequently splits a single region during HIR typeck into multiple distinct regions. As we assume goals to always succeed during borrowck, relying on two occurances of a region being identical during HIR typeck causes ICE. See the now fixed examples in https://github.com/rust-lang/trait-system-refactor-initiative/issues/27 and rust-lang/rust#139409.
We've previously tried to avoid this issue by always *uniquifying* regions when canonicalizing goals. This prevents caching subtrees during canonicalization which resulted in hangs for very large types. People rely on such types in practice, which caused us to revert our attempt to reinstate `#[type_length_limit]` in https://github.com/rust-lang/rust/pull/127670. The complete list of changes here:
- rust-lang/rust#107981
- rust-lang/rust#110180
- rust-lang/rust#114117
- rust-lang/rust#130821
After more consideration, all occurrences of such large types need to happen outside of typeck/borrowck. We know this as we already walk over all types in the MIR body when replacing their regions with nll vars.
This PR therefore enables us to rely on region identity inside of the trait solver by exclusively **uniquifying root goals during HIR typeck**. These are the only goals we assume to hold during borrowck. This is insufficient as type inference variables may "hide" regions we later uniquify. Because of this, we now stash proven goals which depend on inference variables in HIR typeck and reprove them after writeback. This closes https://github.com/rust-lang/trait-system-refactor-initiative/issues/127.
This was originally part of rust-lang/rust#144258 but I've moved it into a separate PR. While I believe we need to rely on region identity to fix the performance issues in some way, I don't know whether rust-lang/rust#144258 is the best approach to actually do so. Regardless of how we deal with the hangs however, this change is necessary and desirable regardless.
r? `@compiler-errors` or `@BoxyUwU`
|
|
|
|
|
|
|
|
[rustdoc] Display total time and compilation time of merged doctests
Fixes rust-lang/rust#144270.
Does it look good to you `@kpreid?`
<img width="908" height="263" alt="image" src="https://github.com/user-attachments/assets/cd5d082d-c4e0-42ed-91dd-bd263b413dcd" />
|
|
Support multiple crate versions in --extern-html-root-url
Rustdoc's `--extern-html-root-url` used to use `tcx.crate_name()` to identify crates, but that used crates' internal names from their metadata, instead of names given to them in `--extern`. That was confusing, because both `--extern…` arguments seem related and use similar syntax. Crucially, this didn't work correctly with Cargo's package aliases or multiple versions of crates.
`sess.opts.externs` lacks `CrateNum`, and `Resolver.extern_prelude` gets destroyed before `rustdoc` has a chance to see it, so I've had to save this mapping in `CStore`.
Just in case, I've kept the previous mapping by crate name as a fallback for crates that weren't matched by their extern name.
Fixes rust-lang/rust#76296
|
|
|
|
[test][run-make] add needs-llvm-components
Add some constraints to run-make tests that require specific target support and will fail without them.
|
|
Make sure to account for the right item universal regions in borrowck
Fixes https://github.com/rust-lang/rust/issues/144608.
The ICE comes from a mismatch between the liberated late bound regions (i.e. "`ReLateParam`"s) that come from promoting closure outlives, and the regions we have in our region vid mapping from `UniversalRegions`.
When building `UniversalRegions`, we end up using the liberated regions from the binder of the closure's signature:
https://github.com/rust-lang/rust/blob/c8bb4e8a126cf38cff70cea488a3a423a5321954/compiler/rustc_borrowck/src/universal_regions.rs#L521
Notably, this signature may be anonymized if the closure signature being deduced comes from an external constraints:
https://github.com/rust-lang/rust/blob/c8bb4e8a126cf38cff70cea488a3a423a5321954/compiler/rustc_hir_typeck/src/closure.rs#L759-L762
This is true in the test file I committed, where the signature is influenced by the `impl FnMut(&mut ())` RPIT.
However, when promoting a type outlives constraint we end up creating a late bound lifetime mapping that disagrees with those liberated late bound regions we constructed in `UniversalRegions`:
https://github.com/rust-lang/rust/blob/c8bb4e8a126cf38cff70cea488a3a423a5321954/compiler/rustc_borrowck/src/universal_regions.rs#L299
Specifically, in `for_each_late_bound_region_in_item` (which is called by `for_each_late_bound_region_in_recursive_scope`), we were using `tcx.late_bound_vars` which uses the late bound regions *from the HIR*. This query both undercounts the late bound regions (e.g. those that end up being deduced from bounds), and also doesn't account for the fact that we anonymize them in the signature as mentioned above.
https://github.com/rust-lang/rust/blob/c8bb4e8a126cf38cff70cea488a3a423a5321954/compiler/rustc_borrowck/src/universal_regions.rs#L977
This PR fixes that function to use the *correct signature*, which properly considers the bound vars that come from deducing the signature of the closure, and which comes from the closure's args from the `type_of` query.
|
|
Remove `hello_world` directory
Move `tests/ui/hello_world/main.rs` and retire the single-file `tests/ui/hello_world/` directory.
Part of https://github.com/rust-lang/rust/issues/133895.
r? `@jieyouxu`
|
|
Verify llvm-needs-components are not empty and match the --target value
I recently discovered a test with an empty `llvm-needs-components` entry (fixed in rust-lang/rust#143979) which meant that it didn't work correctly when building Rust with a limited set of LLVM targets.
This change makes a pair of improvements to prevent this issue from creeping in again:
* When parsing directives with values, `compiletest` will now raise an error if there is an empty value.
* Improved the `target_specific_tests` tidy checker to map targets to LLVM components, to verify that any existing `llvm-needs-components` contains the target being used.
I also fixed all the issues flagged by the improved tidy checker.
|
|
Add some constraints to run-make tests that require specific target support and will fail without them.
|
|
|
|
Fixes 144621
|
|
This allows us to assume that coverage spans will only be discarded during
codegen in very unusual situations.
|
|
Pick the largest niche even if the largest niche is wrapped around
fixes rust-lang/rust#144388
r? `@scottmcm`
|
|
Update some tests for LLVM 21
Fixes https://github.com/rust-lang/rust/issues/144604.
Fixes https://github.com/rust-lang/rust/issues/144606.
r? `@durin42`
|
|
r=wesleywiser
tests: Test line number in debuginfo for diverging function calls
Closes rust-lang/rust#59558 which just [E-needs-test](https://github.com/rust-lang/rust/issues/59558#issuecomment-1322236891).
The bug seems to have been fixed in **nightly-2021-05-10**:
```sh
for toolchain in nightly-2021-05-09 \
nightly-2021-05-10 \
1.88; do
echo -e "\nWith $toolchain:"
rustc +$toolchain tests/codegen/diverging-function-call-debuginfo.rs --emit llvm-ir -o /tmp/out.ll -g -Clto -Copt-level=0
build/x86_64-unknown-linux-gnu/ci-llvm/bin/FileCheck --input-file /tmp/out.ll tests/codegen/diverging-function-call-debuginfo.rs --check-prefix=CHECK --dump-input-context 10 2>/dev/null && echo OK || echo FAIL
done
```
```
With nightly-2021-05-09:
FAIL
With nightly-2021-05-10:
OK
With 1.88:
OK
```
which gives the following list of candidate commits. Not clear which one it is exactly but it doesn't matter much since we can confirm that the test works. I have confirmed locally that with **nightly-2021-05-09** we get `line: 0` for the last call.
<details>
<summary>click to expand</summary>
```
$ git log ^881c1ac408d93bb7adaa3a51dabab9266e82eee8 ca82264ec7556a6011b9d3f1b2fd4c7cd0bc8ae2 --no-merges --oneline
```
f25aa5767f0 Remove unused `opt_span_warn` function
ebbc9495755 Note why `Handler::fatal` is different from `Sesssion::fatal`
96509b48358 Make `Diagnostic::span_fatal` unconditionally raise an error
e49f4471aae Remove some unnecessary uses of `struct_span_fatal`
955fdaea4a1 Rename `Parser::span_fatal_err` -> `Parser::span_err`
4b7c8b0b53c Add `#[track_caller]` to `FakeDefId::expect_real()`
ba13225ba1e Remove `FakeDefId::expect_local()`
020d83d9f5f Enable `-W semicolon_in_expressions_from_macros` in bootstrap
1b928ff8f8b Update LLVM submodule
c2b15a6b641 Support -C passes in NewPM
5519cbfe334 Don't force -O1 with ThinLTO
7c4989ab707 Drop -opt-bisect-limit=0 flag from test
db140de8f29 Explicitly register GCOV profiling pass as well
5ecbe7fcf8b Explicitly register instrprof pass
0318883cd62 Make -Z new-llvm-pass-manager an Option<bool>
0367e24f944 Avoid predecessors having Drop impls
</details>
|
|
|
|
|
|
|
|
|
|
r=petrochenkov
Account for `.yield` in illegal postfix operator message
Fixes rust-lang/rust#144527
|
|
expand: Micro-optimize prelude injection
Use `splice` to avoid shifting the other items twice.
Put `extern crate std;` first so it's already resolved when we resolve `::std::prelude::rust_20XX`.
|
|
Simplify `align_of_val::<[T]>(…)` → `align_of::<T>()`
I spotted this while working on the inliner (rust-lang/rust#144561). In particular, if [`Layout::for_value`](https://doc.rust-lang.org/std/alloc/struct.Layout.html#method.for_value) inlines, then it can be pretty easy to end up with an `align_of_val::<[T]>` today (demo: <https://rust.godbolt.org/z/Tesnscj4a>) where we can save at least a block, if not more, by using the version that's an rvalue and not a call.
|
|
coverage: Treat `#[automatically_derived]` as `#[coverage(off)]`
One of the contributing factors behind https://github.com/rust-lang/rust/issues/141577#issuecomment-3120667286 was the presence of derive-macro-generated code containing nested closures.
Coverage instrumentation already has a heuristic for skipping code marked with `#[automatically_derived]` (rust-lang/rust#120185), because derived code is usually not worth instrumenting, and also has a tendency to trigger vexing edge-case bugs in coverage instrumentation or coverage codegen.
However, the existing heuristic only applied to the associated items directly within an auto-derived impl block, and had no effect on closures or nested items within those associated items.
This PR therefore extends the search for `#[coverage(..)]` attributes to also treat `#[automatically_derived]` as an implied `#[coverage(off)]` for the purposes of coverage instrumentation.
---
This change doesn’t rule out an entire category of bugs, because it only affects code that actually uses the auto-derived attribute. But it should reduce the overall chance of edge-case macro span bugs being observed in the wild.
|
|
On LLVM 21 additional %esp adjustments are generated. Don't use
NEXT to allow these.
|
|
Add a test case for the issue #129882
It ensures that using the `generic_const_exprs` feature in a library crate without enabling it in a dependent crate does not lead to an ICE.
Closes https://github.com/rust-lang/rust/issues/129882.
|
|
feat: Right align line numbers
As part of my work on getting `annotate-snipptes` to be used as `rustc`'s renderer, I realized that `rustc` left-aligned line numbers, while `annotate-snippets` right-aligned them. This PR switches `rustc` to right-align the line numbers, matching `annotate-snippets`. In practice, this change isn't very noticeable in day-to-day output, as it only shows up when a diagnostic span contains line numbers with different lengths (9->10, 99->100, 999->1000, etc.).
`rustc`
```
error[E0412]: cannot find type `F` in this scope
--> $DIR/ui-testing-optout.rs:92:10
|
4 | type A = B;
| ----------- similarly named type alias `A` defined here
...
92 | type E = F;
| ^ help: a type alias with a similar name exists: `A`
```
`annotate-snippets`
```
error[E0412]: cannot find type `F` in this scope
--> $DIR/ui-testing-optout.rs:92:10
|
4 | type A = B;
| ----------- similarly named type alias `A` defined here
...
92 | type E = F;
| ^ help: a type alias with a similar name exists: `A`
```
r? ``@compiler-errors``
|
