| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#138285 (Stabilize `repr128`)
- rust-lang/rust#139994 (add `CStr::display`)
- rust-lang/rust#141571 (coretests: extend and simplify float tests)
- rust-lang/rust#141656 (CI: Add cargo tests to aarch64-apple-darwin)
Failed merges:
- rust-lang/rust#141430 (remove `visit_clobber` and move `DummyAstNode` to `rustc_expand`)
- rust-lang/rust#141636 (avoid some usages of `&mut P<T>` in AST visitors)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
coretests: extend and simplify float tests
Also de-duplicate tests by removing a ui test that duplicates the tests in core.
r? `@tgross35`
|
|
Stabilize `repr128`
## Stabilisation report
The `repr128` feature ([tracking issue](https://github.com/rust-lang/rust/issues/56071)) allows the use of `#[repr(u128)]` and `#[repr(i128)]` on enums in the same way that other primitive representations such as `#[repr(u64)]` can be used. For example:
```rust
#[repr(u128)]
enum Foo {
One = 1,
Two,
Big = u128::MAX,
}
#[repr(i128)]
enum Bar {
HasThing(u16) = 42,
HasSomethingElse(i64) = u64::MAX as i128 + 1,
HasNothing,
}
```
This is the final part of adding 128-bit integers to Rust ([RFC 1504](https://rust-lang.github.io/rfcs/1504-int128.html)); all other parts of 128-bit integer support were stabilised in #49101 back in 2018.
From a design perspective, `#[repr(u128)]`/`#[repr(i128)]` function like `#[repr(u64)]`/`#[repr(i64)]` but for 128-bit integers instead of 64-bit integers. The only differences are:
- FFI safety: as `u128`/`i128` are not currently considered FFI safe, neither are `#[repr(u128)]`/`#[repr(i128)]` enums (I discovered this wasn't the case while drafting this stabilisation report, so I have submitted #138282 to fix this).
- Debug info: while none of the major debuggers currently support 128-bit integers, as of LLVM 20 `rustc` will emit valid debuginfo for both DWARF and PDB (PDB makes use of the same natvis that is also used for all enums with fields, whereas DWARF has native support).
Tests for `#[repr(u128)]`/`#[repr(i128)]` enums include:
- [ui/enum-discriminant/repr128.rs](https://github.com/rust-lang/rust/blob/385970f0c1fd0c09bac426b02f38300c0b1ba9a2/tests/ui/enum-discriminant/repr128.rs): checks that 128-bit enum discriminants have the correct values.
- [debuginfo/msvc-pretty-enums.rs](https://github.com/rust-lang/rust/blob/385970f0c1fd0c09bac426b02f38300c0b1ba9a2/tests/debuginfo/msvc-pretty-enums.rs): checks the PDB debuginfo is correct.
- [run-make/repr128-dwarf](https://github.com/rust-lang/rust/blob/385970f0c1fd0c09bac426b02f38300c0b1ba9a2/tests/run-make/repr128-dwarf/rmake.rs): checks the DWARF debuginfo is correct.
Stabilising this feature does not require any changes to the Rust Reference as [the documentation on primitive representations](https://doc.rust-lang.org/nightly/reference/type-layout.html#r-layout.repr.primitive.intro) already includes `u128` and `i128`.
Closes #56071
Closes https://github.com/rust-lang/reference/issues/1368
r? lang
```@rustbot``` label +I-lang-nominated +T-lang
|
|
Handle ed2021 precise capturing of unsafe binder
Missing pieces from last pr.
r? oli-obk
Fixes https://github.com/rust-lang/rust/issues/141655
|
|
Emit warning while outputs is not exe and prints linkage info
cc #137384
```bash
$ rustc +stage1 /dev/null --print native-static-libs --crate-type staticlib --emit metadata
warning: skipping link step due to conflict: cannot output linkage information without emitting executable
note: consider emitting executable to print link information
warning: 1 warning emitted
```
|
|
GCI: At their def site, actually wfcheck the where-clause & always eval free lifetime-generic constants
* 1st commit: Partially addresses [#136204](https://github.com/rust-lang/rust/issues/136204) by turning const eval errors from post to pre-mono for free lifetime-generic constants.
* As the linked issue/comment states, on master there's a difference between `const _: () = panic!();` (pre-mono error) and `const _<'a>: () = panic!();` (post-mono error) which feels wrong.
* With this PR, both become pre-mono ones!
* 2nd commit: Oof, yeah, I missed that in the initial impl!
This doesn't fully address #136204 because I still haven't figured out how & where to properly & best suppress const eval of free constants whose predicates don't hold at the def site. The motivating example is `const _UNUSED: () = () where for<'_delay> String: Copy;` which can also be found over at the tracking issue #113521.
r? compiler-errors or reassign
|
|
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#140369 (Add data_ptr method to Mutex and RwLock)
- rust-lang/rust#140697 (Split `autodiff` into `autodiff_forward` and `autodiff_reverse`)
- rust-lang/rust#141404 (Improve intrinsic handling in cg_ssa)
- rust-lang/rust#141411 (rustdoc: linking to a local proc macro no longer warns)
- rust-lang/rust#141548 (consider glob imports in cfg suggestion)
- rust-lang/rust#141627 (Drop-build cleanups)
- rust-lang/rust#141670 (Fix ICE in tokenstream with contracts from parser recovery)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=nnethercote
Fix ICE in tokenstream with contracts from parser recovery
Fixes rust-lang/rust#140683
After two times of parsing error, the `recover_stmt_` constructs an error ast, then when we expand macors, the invalid tokenstream triggered ICE because of mismatched delims.
Expected `{` and get other tokens is an obvious error message, too much effort on recovery may introduce noise.
r? ```@nnethercote```
|
|
consider glob imports in cfg suggestion
Fixes rust-lang/rust#141256
r? ```@petrochenkov```
|
|
r=GuillaumeGomez
rustdoc: linking to a local proc macro no longer warns
fixes https://github.com/rust-lang/rust/issues/91274
tried to keep the fix general in case we ever have any other kind of item that occupies
multiple namespaces simultaniously.
|
|
Split `autodiff` into `autodiff_forward` and `autodiff_reverse`
This PR splits `#[autodiff]` macro so `#[autodiff(df, Reverse, args)]` would become `#[autodiff_reverse(df, args)]` and `#[autodiff(df, Forward, args)]` would become `#[autodiff_forwad(df, args)]`.
|
|
ci: move tests from x86_64-gnu-llvm-19 job to aarch64
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#140367 (add `asm_cfg`: `#[cfg(...)]` within `asm!`)
- rust-lang/rust#140894 (Make check-cfg diagnostics work in `#[doc(cfg(..))]`)
- rust-lang/rust#141252 (gvn: bail out unavoidable non-ssa locals in repeat)
- rust-lang/rust#141517 (rustdoc: use descriptive tooltip if doctest is conditionally ignored)
- rust-lang/rust#141551 (Make two transmute-related MIR lints into HIR lint)
- rust-lang/rust#141591 (ci: fix llvm test coverage)
- rust-lang/rust#141647 (Bump master `stage0` compiler)
- rust-lang/rust#141659 (Add `Result::map_or_default` and `Option::map_or_default`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Make two transmute-related MIR lints into HIR lint
Make `PTR_TO_INTEGER_TRANSMUTE_IN_CONSTS` (rust-lang/rust#130540) and `UNNECESSARY_TRANSMUTES` (rust-lang/rust#136083) into "normal" HIR-based lints.
Funny enough this came up in the review of the latter (https://github.com/rust-lang/rust/pull/136083#issuecomment-2614301413), but I guess it just was overlooked.
But anywyas, there's no reason for these to be MIR lints; in fact, it makes the suggestions for them a bit more complicated than necessary.
Note that there's probably a few more simplifications and improvements to be done here. Follow-ups can be done in a separate PR, especially if they're about the messaging and suggestions themselves, which I didn't write.
|
|
lolbinarycat:rustdoc-doctest-tooltip-ignore-141092, r=notriddle
rustdoc: use descriptive tooltip if doctest is conditionally ignored
fixes https://github.com/rust-lang/rust/issues/141092
here's what it looks like now:
|
|
gvn: bail out unavoidable non-ssa locals in repeat
Fixes #141251.
We cannot transform `*elem` to `array[idx1]` in the following code, as `idx1` has already been modified.
```rust
mir! {
let array;
let elem;
{
array = [*val; 5];
elem = &array[idx1];
idx1 = idx2;
RET = *elem;
Return()
}
}
```
Perhaps I could transform it to `array[0]`, but I prefer the conservative approach.
r? mir-opt
|
|
Make check-cfg diagnostics work in `#[doc(cfg(..))]`
This PR makes it so that the check-cfg `unexpected_cfgs` lint, is correctly emitted in `rustdoc`'s `#[doc(cfg(..))]`.
This is achieved by adding a custom trait to `cfg_matches` (the method that emits the lint) which permits `rustc` and `rustdoc` to each have their way to emitting lints (via buffered lints/AST for `rustc` and via `TyCtxt`/HIR for `rustdoc`).
The reason this is required is because buffered lints operates on the AST but `rustdoc` uses the HIR and by the time `rustdoc` calls `cfg_matches` we are way passed the point where buffered lints have been drain and emitted.
Best reviewed commit by commit.
r? `@jieyouxu` (for the compiler part)
r? `@GuillaumeGomez` (for the rustdoc part)
|
|
add `asm_cfg`: `#[cfg(...)]` within `asm!`
tracking issue: https://github.com/rust-lang/rust/issues/140364
blocked on: https://github.com/rust-lang/rust/pull/140490
This feature was discussed in https://github.com/rust-lang/rust/issues/140279. It allows configuring templates and operands in the assembly macros, for example:
```rust
asm!( // or global_asm! or naked_asm!
"nop",
#[cfg(target_feature = "sse2")]
"nop",
// ...
#[cfg(target_feature = "sse2")]
a = const 123, // only used on sse2
);
```
r? `@tgross35`
cc `@traviscross` `@Amanieu`
Now builds on https://github.com/rust-lang/rust/pull/140490, which should be merged first.
|
|
Add some track_caller info to precondition panics
Currently, when you encounter a precondition check, you'll always get the caller location of the implementation of the precondition checks. But with this PR, you'll be told the location of the invalid call. Which is useful.
I thought of this while looking at https://github.com/rust-lang/rust/pull/129642#issuecomment-2311703898.
The changes to `tests/ui/const*` happen because the const-eval interpreter skips `#[track_caller]` frames in its backtraces.
The perf implications of this are:
* Increased debug binary sizes. The caller_location implementation requires that the additional data we want to display here be stored in const allocations, which are deduplicated but not across crates. There is no impact on optimized build sizes. The panic path and the caller location data get optimized out.
* The compile time hit to opt-incr-patched bitmaps happens because the patch changes the line number of some function calls with precondition checks, causing us to go from 0 dirty CGUs to 1 dirty CGU.
* The other compile time hits are marginal but real, and due to doing a handful of new queries. Adding more useful data isn't completely free.
|
|
tests: mark option-niche-eq as fixed on LLVM 21
Some combination of recent Rust changes (between 3d86494a0d01 and aa57e46e24a4 from what I can tell) and changes in LLVM 21 (not recently, as best I can tell) have caused this test to start showing the behavior we want, so it's time to move this test to a proper place and mark it as fixed on LLVM 21.
~~Probably "fixes" rust-lang/rust#49892, but I'll let others make that call.~~
Closes rust-lang/rust#49892 unless we want to break out a dedicated issue for `Option<bool>::eq` on LLVM 20 (seems low-value).
`@rustbot` label llvm-main
|
|
coverage: Revert "unused local file IDs" due to empty function names
The changes to coverage metadata generation in rust-lang/rust#140847 appear to be the most likely cause of the `function name is empty` errors reported in rust-lang/rust#141577.
If that guess is correct, great. If not, no big deal.
---
This reverts commit 3b22c21dd8c30f499051fe7a758ca0e5d81eb638, reversing changes made to 5f292eea6d63abbd26f1e6e00a0b8cf21d828d7d.
r? ghost
|
|
Fabian-Gruenbichler:mr/test-version-check-rpath-false, r=jieyouxu
test: convert version_check ui test to run-make
else it breaks with `rpath=false`.
Fixes: rust-lang/rust#141579
|
|
|
|
Co-authored-by: Michael Goulet <michael@errs.io>
|
|
Some combination of recent Rust changes (between 3d86494a0d01 and
aa57e46e24a4 from what I can tell) and changes in LLVM 21 (not recently,
as best I can tell) have caused this test to start showing the behavior
we want, so it's time to move this test to a proper place and mark it as
fixed on LLVM 21.
|
|
fixes https://github.com/rust-lang/rust/issues/91274
Co-authored-by: Guillaume Gomez <guillaume1.gomez@gmail.com>
|
|
This reverts commit 3b22c21dd8c30f499051fe7a758ca0e5d81eb638, reversing
changes made to 5f292eea6d63abbd26f1e6e00a0b8cf21d828d7d.
|
|
Add `generic_arg_infer` test
I think most of our existing tests around behaviour of repeat expr inferred counts fail by not having enough inference progress, rather than by having enough inference progress but the element not actually implementing `Copy`.
|
|
Add missing edition directives for async-await tests
These tests specifically test 2015 edition behavior
|
|
Support `opaque_types_defined_by` for `SyntheticCoroutineBody`
We create a synthetic MIR body for the `AsyncFnOnce` impl for async closures. That body goes through all passes that a regular body does, including promotion.
Promotion sometimes requires computing that the type of an rvalue is `Freeze`, which requires computing the typing env of a body. This requires calling `opaque_types_defined_by` on the body's def id, which leads to an ICE today since we don't expect that query to be called for synthetic bodies.
While we could fix this by, for example, computing the typeck root of the body before calling a `TypingEnv` constructor, I think it's appropriate to do a more general fix here since I think it's reasonable that other passes might do analysis too.
Fixes rust-lang/rust#141466
r? ```@lcnr``` or ```@oli-obk```
|
|
r=compiler-errors
Use more detailed spans in dyn compat errors within bodies
Within bodies we can employ the full dyn compat check query instead of only doing the minimal hir ty lowerer one. This in turn gives us better spans and also silences many follow-up duplicate or bogus errors.
alternative to https://github.com/rust-lang/rust/pull/141439, tho I think I could turn the delayed bug from that one into a bug now instead of having an error code path.
r? `@compiler-errors`
cc `@fmease`
|
|
Pull out dedicated `cfg_version` syntax test from feature gate test
Tracking issue: rust-lang/rust#64796.
Closes rust-lang/rust#141452, as a follow-up to https://github.com/rust-lang/rust/pull/141413#discussion_r2104490809 (point 3 of that is probably too pedantic).
The feature gate test was dual-purposing causing feature gate errors to distract from syntax exercises.
``@rustbot`` label +F-cfg_version
r? ``@est31``
|
|
Improve `ambiguous_wide_pointer_comparisons` lint compare diagnostics
This PR improves the `ambiguous_wide_pointer_comparisons` lint compare diagnostics: `cmp`/`partial_cmp`, but also the operators `<`/`>`/`>=`/`<=`, by:
1. removing the reference to `std::ptr::addr_eq` which only works for equality
2. and adding an `#[expect]` suggestion for keeping the current behavior
Fixes rust-lang/rust#141510
|
|
Fix malformed suggestion for E0061 when method is a macro token in macro context
fixes #140512
before
```rust
3 - <Self>::$method(8)
3 + <Self>::<Self>::$method(8, /* u8 */)
```
now
```rust
3 | <Self>::$method(8, /* u8 */)
| ++++++++++
```
|
|
else it breaks with `rpath=false`.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
|
|
|
|
|
|
|
|
|
|
Enable xray support for Mac
https://github.com/rust-lang/rust/issues/102921
Upstream has supported Mac for a while, let's enable it.
I've tested it on M4 and it generates nop sled correctly.
* https://maskray.me/blog/2023-06-18-port-llvm-xray-to-apple-systems
* https://github.com/llvm/llvm-project/blob/llvmorg-20.1.4/clang/lib/Driver/XRayArgs.cpp#L31
try-job: x86_64-apple-1
try-job: aarch64-apple
|
|
|
|
|
|
Fix `unused_braces` lint suggestion when encountering attributes
This PR fixes the `unused_braces` lint suggestion when encountering attributes by not removing them in the suggestion.
Fixes rust-lang/rust#141549
|
|
Deduplicate dyn compatibility violations due to coercion
Don't unnecessarily emit dyn compatibility violations due to coercion to a non-dyn-compatible target type.
For us to even have that target type, we would have had to write `dyn Trait` somewhere in source, and that would have led to us *already* emitting a dyn compatibility violation when checking that user written type is WF.
r? oli-obk
|
