| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
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.
|
|
Make it more idiomatic with the new run-make infra
|
|
|
|
|
|
`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
|
|
In rustc it doesn't really matter what the order of the witnesses is, but I'm planning to use the witnesses for implementing the "add missing match arms" assist in rust-analyzer, and there `true` before `false` is the natural order (like `Some` before `None`), and also what the current assist does.
The current order doesn't seem to be intentional; the code was created when bool ctors became their own thing, not just int ctors, but for integer, 0 before 1 is indeed the natural order.
|
|
|
|
recursive non-enum types
|
|
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#144226 (Do not assert layout in KnownPanicsLint.)
- rust-lang/rust#144385 (Optimize performance by inline in macro hygiene system)
- rust-lang/rust#144454 (move uefi test to run-make)
- rust-lang/rust#144455 (Unify LLVM ctlz/cttz intrinsic generation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
move uefi test to run-make
Turn the `uefi` test into a more standard `run-make` test, and execute it using the `test-various` CI job like before.
This is just a straightforward translation of the python code, but using `run-make` to supply the target (hence the 3 separate calls in the docker file).
r? ```@jieyouxu```
cc ```@nicholasbishop```
try-job: test-various
|
|
Do not assert layout in KnownPanicsLint.
Fixes rust-lang/rust#121176
Fixes rust-lang/rust#129109
Fixes rust-lang/rust#130970
Fixes rust-lang/rust#131347
Fixes rust-lang/rust#139872
Fixes rust-lang/rust#140332
|
|
No longer need `alloca`s for consuming `Result<!, i32>` and similar
In optimized builds GVN gets rid of these already, but in `opt-level=0` we actually make `alloca`s for this, which particularly impacts `?`-style things that use actually-only-one-variant types like this.
While doing so, rewrite `LocalAnalyzer::process_place` to be non-recursive, solving a 6+ year old FIXME.
r? codegen
|
|
`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()`.
Fixes: https://github.com/rust-lang/rust/issues/144521
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Revert "coverage: Enlarge empty spans during MIR instrumentation, not codegen"
Surprisingly, rust-lang/rust#144298 alone (extracted from rust-lang/rust#140847) was enough to re-trigger the failures observed in https://github.com/rust-lang/rust/issues/141577#issuecomment-3120667286.
---
This reverts commit f877aa7d14916f71a2f88c6d4c009e7ded7684c4.
---
r? ghost
|
|
canonicalize build root in `tests/run-make/linker-warning`
r? jieyouxu
This is similar to rust-lang/rust#139823 -- the test fails for me because my build dir is a symlink.
|
|
tests: aarch64-outline-atomics: Remove hardcoded target
Since this test is limited to aarch64 and linux hosts, the `--target` flag is entirely unnecessary and only breaks this on musl hosts. Let the compiler use the default target instead.
|
|
Stop compilation early if macro expansion failed
Fixes rust-lang/rust#116180.
So there isn't really a type that is central for macro expansion and some errors are actually emitted (because the resolution happens after the expansion I suppose) after the expansion pass (like "not found macro"). Sometimes, errors are only emitted on the second "try" (to improve error output). So I couldn't reach a similar solution than what was done in https://github.com/rust-lang/rust/pull/133937 and suggested by ````@estebank```` in https://github.com/rust-lang/rust/issues/116180#issuecomment-3109468922. But maybe I missed something?
So in the end, I realized that there is method called every time (except one, described below) a macro error is actually emitted: `ExtCtxt::trace_macros_diag`. Considering I updated what it did, I renamed it into `macro_error_and_trace_macros_diag` to better reflect it.
There is only one call of `trace_macros_diag` which isn't reporting an error but just used for `macro_trace` feature, so I kept it as is.
r? ````@oli-obk````
|
|
r=RalfJung
test using multiple c-variadic ABIs in the same program
tracking issue: https://github.com/rust-lang/rust/issues/100189
Check that multiple c-variadic calling conventions can be used in the same program.
Clang and gcc reject defining functions with a non-default calling convention and a variable
argument list, so C programs that use multiple c-variadic calling conventions are unlikely
to come up. Here we validate that our codegen backends do in fact generate correct code.
(CI will not run this test because it runs on aarch64, I would like to at least test that this runs on windows)
try-job: `x86_64-gnu`
try-job: `x86_64-msvc-*`
try-job: `x86_64-apple-2`
|
|
add codegen test for variadics
This is a part of https://github.com/rust-lang/rust/pull/144066 that can land without FCP.
|
|
Let `codegen_transmute_operand` just handle everything
When combined with rust-lang/rust#143720, this means `rvalue_creates_operand` can just return `true` for *every* `Rvalue`. (A future PR could consider removing it, though just letting it optimize out is fine for now.)
It's nicer anyway, IMHO, because it avoids needing the layout checks to be consistent in the two places, and thus is an overall reduction in code. Plus it's a more helpful building block when used in other places this way.
(TBH, it probably would have been better to have it this way the whole time, but I clearly didn't understand `rvalue_creates_operand` when I originally wrote rust-lang/rust#109843.)
|
|
|
|
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
Allow pretty printing paths with `-Zself-profile-events=args`
`-Zself-profile-events=args` is pretty heavy and can pretty print a lot of stuff. Rather than hunting down specific cases where this happens, I'd just allow calling `trimmed_def_paths` in this mode.
Fixes: https://github.com/rust-lang/rust/issues/144457
r? `@RalfJung`
|
|
Suggest unwrapping when private method name is available in inner type
Given
```rust
fn main() {
let maybe_vec = Some(vec![1,2,3]);
assert_eq!(maybe_vec.len(), 3);
}
```
suggest unwraping `maybe_vec` to call `.len()` on the `Vec<_>`.
```
error[E0624]: method `len` is private
--> $DIR/enum-method-probe.rs:61:9
|
LL | res.len();
| ^^^ private method
--> $SRC_DIR/core/src/option.rs:LL:COL
|
= note: private method defined here
|
note: the method `len` exists on the type `Vec<{integer}>`
--> $SRC_DIR/alloc/src/vec/mod.rs:LL:COL
help: consider using `Option::expect` to unwrap the `Vec<{integer}>` value, panicking if the value is an `Option::None`
|
LL | res.expect("REASON").len();
| +++++++++++++++++
```
When a method isn't available, we emit E0599, but when it is private we emit E0624. We now just invoke the same suggestion logic from the later that we already did in the former.
Fix rust-lang/rust#143795.
|
|
jplatte:matches-allow-non_exhaustive_omitted_patterns, r=Nadrieril
Disable non_exhaustive_omitted_patterns within matches! macro
Closes rust-lang/rust#117304.
I believe I can skip all of the bootstrap stuff mentioned in https://github.com/rust-lang/rust/issues/117304#issuecomment-1784414453 due to https://blog.rust-lang.org/inside-rust/2025/05/29/redesigning-the-initial-bootstrap-sequence/, right?
cc `@Jules-Bertholet`
|
|
Let's wait with lldb testing until the test works properly with gdb.
|
|
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#140871 (Don't lint against named labels in `naked_asm!`)
- rust-lang/rust#141663 (rustdoc: add ways of collapsing all impl blocks)
- rust-lang/rust#143272 (Upgrade the `fortanix-sgx-abi` dependency)
- rust-lang/rust#143585 (`loop_match`: suggest extracting to a `const` item)
- rust-lang/rust#143698 (Fix unused_parens false positive)
- rust-lang/rust#143859 (Guarantee 8 bytes of alignment in Thread::into_raw)
- rust-lang/rust#144160 (tests: debuginfo: Work around or disable broken tests on powerpc)
- rust-lang/rust#144412 (Small cleanup: Use LocalKey<Cell> methods more)
- rust-lang/rust#144431 (Disable has_reliable_f128_math on musl targets)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Disable has_reliable_f128_math on musl targets
musl does not implement the symbols required by rustc for f128 maths. Disable the associated cfg for all musl targets and adjust the tests accordingly.
Closes rust-lang/rust#144423
|
|
tests: debuginfo: Work around or disable broken tests on powerpc
f16 support for PowerPC has issues in LLVM, therefore we need a small workaround to prevent LLVM from emitting symbols that don't exist for PowerPC yet.
It also appears that rust-lang/rust#128973 applies to PowerPC targets as well, though I've only tested 64-bit Linux targets.
|
|
Fix unused_parens false positive
Resolves rust-lang/rust#143653.
The "no bounds exception" was indiscriminately set to `OneBound` for referents and pointees. However, if the reference or pointer type itself appears in no-bounds position, any constraints it has must be propagated.
```rust
// unused parens: not in no-bounds position
fn foo(_: Box<(dyn Send)>) {}
// unused parens: in no-bounds position, but one-bound exception applies
fn bar(_: Box<dyn Fn(&u32) -> &(dyn Send)>) {}
// *NOT* unused parens: in no-bounds position, but no exceptions to be made
fn baz(_: Box<dyn Fn(&u32) -> &(dyn Send) + Send>) {}
```
|
|
`loop_match`: suggest extracting to a `const` item
tracking issue: https://github.com/rust-lang/rust/issues/132306
fixes https://github.com/rust-lang/rust/issues/143310
fixes https://github.com/rust-lang/rust/issues/143936
|
