| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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``
|
|
Ensure external paths passed via flags end up in rustdoc depinfo
rustdoc has many flags to pass external HTML/Markdown/CSS files that end up in the build. These need to be recorded in depinfo so that Cargo will rebuild the crate if they change.
|
|
thread name in stack overflow message
Fixes rust-lang/rust#144481, which is caused by the thread name not being initialised yet when setting up the stack overflow information. Unfortunately, the stack overflow UI test did not test for the correct thread name being present, and testing this separately didn't occur to me when writing https://github.com/rust-lang/rust/pull/140628.
This PR contains the smallest possible fix I could think of: passing the thread name explicitly to the platform thread creation function. In the future I'd very much like to explore some possibilities around merging the thread packet and thread handle into one structure and using that in the platform code instead – but that's best left for another PR.
This PR also amends the stack overflow test to check for thread names, so we don't run into this again.
``@rustbot`` label +beta-nominated
|
|
fix: Reject upvar scrutinees for `loop_match`
Fixes https://github.com/rust-lang/rust/issues/144051
I think we should reject upvars as they are not locals but somewhat like field access
|
|
r=wesleywiser
fix(debuginfo): disable overflow check for recursive non-enum types
Commit b10edb4 introduce an overflow check when generating debuginfo for expanding recursive types. While this check works correctly for enums, it can incorrectly prune valid debug information for structures.
For example see rust-lang/rust#143241 (https://github.com/rust-lang/rust/issues/143241#issuecomment-3073721477). Furthermore, for structures such check does not make sense, since structures with recursively expanding types simply will not compile (there is a `hir_analysis_recursive_generic_parameter` for that).
closes rust-lang/rust#143241
|
|
Implementation: `#[feature(sync_nonpoison)]`, `#[feature(nonpoison_mutex)]`
Continuation of https://github.com/rust-lang/rust/pull/134663
Tracking Issue: https://github.com/rust-lang/rust/issues/134645
This PR implements a new `sync/nonpoison` module, as well as the `nonpoison` variant of the `Mutex` lock.
There are 2 main changes here, the first is the new `nonpoison::mutex` module, and the second is the `mutex` integration tests.
For the `nonpoison::mutex` module, I did my best to align it with the current state of the `poison::mutex` module. This means that several unstable features (`mapped_lock_guards`, `lock_value_accessors`, and `mutex_data_ptr`) are also in the new `nonpoison::mutex` module, under their respective feature gates. Everything else in that file is under the correct feature gate (`#[unstable(feature = "nonpoison_mutex", issue = "134645")]`).
Everything in the `nonpoison::mutex` file is essentially identical in spirit, as we are simply removing the error case from the original `poison::mutex`.
The second big change is in the integration tests. I created a macro called that allows us to duplicate tests that are "generic" over the different mutex types, in that the poison mutex is always `unwrap`ped.
~~I think that there is an argument against doing this, as it can make the tests a bit harder to understand (and language server capabilities are weaker within macros), but I think the benefit of code deduplication here is worth it. Note that it is definitely possible to generalize this (with a few tweaks) to testing the other `nonpoison` locks when they eventually get implemented, but I'll leave that for a later discussion.~~
|
|
The two xors get folded into the select.
|
|
This is now printed on the same line. Use NEXT/SAME depending on
the LLVM version.
|
|
|
|
|
|
Adds the equivalent `nonpoison` types to the `poison::mutex` module.
These types and implementations are gated under the `nonpoison_mutex`
feature gate.
Also blesses the ui tests that now have a name conflicts (because these
types no longer have unique names). The full path distinguishes the
different types.
Co-authored-by: Aandreba <aandreba@gmail.com>
Co-authored-by: Trevor Gross <tmgross@umich.edu>
|
|
attribute.
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.
|
|
|
|
|
|
|
|
The bug was triggered by a particular usage of the `?` try operator in a
proc-macro expansion.
Thanks to lqd for the minimization.
Co-authored-by: Rémy Rakic <remy.rakic+github@gmail.com>
|
|
|
|
rustdoc has many flags to pass external HTML/Markdown/CSS files that end
up in the build. These need to be recorded in depinfo so that Cargo will
rebuild the crate if they change.
|
|
|
|
|
|
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`.
|
|
|
|
|
|
Allow more MIR SROA
This removes some guards on SROA that are no longer needed:
- With https://github.com/rust-lang/compiler-team/issues/838 it no longer needs to check for SIMD
- With https://github.com/rust-lang/compiler-team/issues/807 it no longer needs to check for niches
- This means that `Wrapper(char)` and `Pin<&mut T>` can get SRoA'd now, where previously they weren't because the check was banning SRaA for anything with a niche -- not just things with `#[rustc_layout_scalar_valid_range_*]`.
- Technically rust-lang/rust#133652 isn't complete yet, but `NonZero` and `NonNull` have already moved over, so this is fine. At worst this will mean that LLVM gets less `!range` metadata on something that wasn't already fixed by rust-lang/rust#133651 or rust-lang/rust#135236, but that's still sound, and unblocking general SRoA is worth that tradeoff.
|
|
|
|
`tests/ui/issues/`: The Issues Strike Back [1/N]
I believe I’ve finally brought [my program](https://github.com/Kivooeo/test-manager) to life -- it now handles multiple test moves in one go: plain moves first, then a gentle touch on each file depends on given options. The process should be much smoother now.
Of course, I won’t rush through everything in a few days -- that would be unkind to `@Oneirical.` I’ll pace myself. And also I can't have more than one such PR because `issues.txt` will conflict with previous parts after merging them which is not fun as well.
This PR is just that: first commit - moves; second - regression comments and the occasional .stderr reblesses, also issue.txt and tidy changes. Nothing special, but progress nonetheless. This is for the purpose of preserving test file history during restructuring
Part of https://github.com/rust-lang/rust/issues/133895.
r? `@jieyouxu`
|
|
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#143607 (Port the proc macro attributes to the new attribute parsing infrastructure)
- rust-lang/rust#144471 (Remove `compiler-builtins-{no-asm,mangled-names}`)
- rust-lang/rust#144495 (bump cargo_metadata)
- rust-lang/rust#144523 (rustdoc: save target modifiers)
- rust-lang/rust#144534 (check_static_item: explain should_check_for_sync choices)
- rust-lang/rust#144535 (miri: for ABI mismatch errors, say which argument is the problem)
Failed merges:
- rust-lang/rust#144536 (miri subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustdoc: save target modifiers
`rustdoc` was filling a `target_modifiers` variable, but it was not using the result.
In turn, that means that trying to use a dependency that set a target modifier fails.
For instance, running:
```sh
RUSTC_BOOTSTRAP=1 rustc --edition=2024 --target=aarch64-unknown-none-softfloat --sysroot=/dev/null --emit=metadata -Zfixed-x18 --crate-type rlib --crate-name core $(rustc --print sysroot)/lib/rustlib/src/rust/library/core/src/lib.rs
echo '#![allow(internal_features)]
' | RUSTC_BOOTSTRAP=1 rustdoc --edition=2021 --target=aarch64-unknown-none-softfloat --sysroot=/dev/null -Zfixed-x18 --extern core=libcore.rmeta -
```
will fail with:
```text
error: mixing `-Zfixed-x18` will cause an ABI mismatch in crate `rust_out`
|
= help: the `-Zfixed-x18` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely
= note: unset `-Zfixed-x18` in this crate is incompatible with `-Zfixed-x18=` in dependency `core`
= help: set `-Zfixed-x18=` in this crate or unset `-Zfixed-x18` in `core`
= help: if you are sure this will not cause problems, you may use `-Cunsafe-allow-abi-mismatch=fixed-x18` to silence this error
```
Thus save the targets modifiers in `Options` to then pass it to the session options, so that eventually the diff can be performed as expected in `report_incompatible_target_modifiers()`.
Cc: ``@azhogin``
Fixes: https://github.com/rust-lang/rust/issues/144521
|
|
r=jdonszelmann,traviscross
Port the proc macro attributes to the new attribute parsing infrastructure
Ports `#[proc_macro]`, `#[proc_macro_attribute]`, `#[proc_macro_derive]` and `#[rustc_builtin_macro]` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971351163
I've split this PR into commits for reviewability, and left some comments to clarify things
I did 4 related attributes in one PR because they share a lot of their code and logic, and doing them separately is kind of annoying as I need to leave both the old and new parsing in place then.
r? ``@oli-obk``
cc ``@jdonszelmann``
|
|
Don't special-case llvm.* as nounwind
Certain LLVM intrinsics, such as `llvm.wasm.throw`, can unwind. Marking them as nounwind causes us to skip cleanup of locals and optimize out `catch_unwind` under inlining or when `llvm.wasm.throw` is used directly by user code.
The motivation for forcibly marking llvm.* as nounwind is no longer present: most intrinsics are linked as `extern "C"` or other non-unwinding ABIs, so we won't codegen `invoke` for them anyway.
Closes rust-lang/rust#132416.
`@rustbot` label +T-compiler +A-panic
|
|
|
