| Age | Commit message (Collapse) | Author | Lines |
|---|
|
mir-opt: Do not create storage marks in EarlyOtherwiseBranch
Fixes #141212.
The first commit add `StorageDead` by creating new indirect BB that makes CFG more complicated, but I think it's better to just not create storage marks.
r? mir-opt
|
|
Always consider `const _` items as live for dead code analysis
This PR alters dead code analysis to always consider `const _: () = { ... };` to be live.
This doesn't address the `_name` pattern from https://github.com/rust-lang/rust/issues/142075.
Fixes https://github.com/rust-lang/rust/issues/142104
|
|
Use the in-tree `compiler-builtins` for the sysroot
Many of `std`'s dependency have a dependency on the crates.io `compiler-builtins` when used with the feature `rustc-std-workspace-core`. Use a Cargo patch to select the in-tree version instead.
`compiler-builtins` is also added as a dependency of `rustc-std-workspace-core` so these crates can remove their crates.io dependency in the future.
Zulip discussion: [#t-compiler > Using in-tree compiler-builtins](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Using.20in-tree.20compiler-builtins/with/522445336)
Once this merges, the following PRs will need to make it to a release for the relevant crates:
- https://github.com/rust-lang/getopts/pull/119 (can merge at any time)
- https://github.com/rust-lang/hashbrown/pull/625 (can merge at any time)
- https://github.com/rust-lang/stdarch/pull/1825
- https://github.com/rust-lang/rustc-demangle/pull/80
- https://github.com/rust-lang/cfg-if/pull/84
- https://github.com/unicode-rs/unicode-width/pull/77
The above should cover all tier 1 targets with no `std` features enabled. The remaining cover the rest:
- https://github.com/alexcrichton/dlmalloc-rs/pull/50 (wasm, xous, sgx)
- https://github.com/gimli-rs/gimli/pull/769
- https://github.com/r-efi/r-efi/pull/89 (efi)
- https://github.com/r-efi/r-efi-alloc/pull/9 (efi)
- https://github.com/fortanix/rust-sgx/pull/770 (sgx)
- https://github.com/hermit-os/hermit-rs/pull/718 (hermit)
- https://github.com/bytecodealliance/wasi-rs/pull/108 (wasi)
- https://github.com/gimli-rs/addr2line/pull/345
- https://github.com/oyvindln/adler2/pull/2
- https://github.com/BurntSushi/memchr/pull/180
- https://github.com/Frommi/miniz_oxide/pull/173
- https://github.com/gimli-rs/object/pull/777
try-job: x86_64-gnu
try-job: test-various
|
|
Stabilize `sha512`, `sm3` and `sm4` for x86
This PR stabilizes the feature flag `sha512_sm_x86` (tracking issue rust-lang/rust#126624).
# Public API
The 3 `x86` target features `sha512`, `sm3` and `sm4`, and the associated intrinsics in stdarch.
These target features are very specialized, and are only used to signal the presence of the corresponding CPU instruction. They don't have any nontrivial interaction with the ABI (contrary to something like AVX), and serve the only purpose of enabling 10 stdarch intrinsics, all of which have been implemented and propagated to rustc via a stdarch submodule update.
Also, these were added in LLVM17, and as the minimum LLVM required for rustc is LLVM19, we are safe in that front too!
# Associated PRs
- rust-lang/rust#126704
- rust-lang/stdarch#1592
- rust-lang/stdarch#1790
- rust-lang/rust#140389 (stdarch submodule update)
- rust-lang/stdarch#1796 (stabilizing the runtime detection and intrinsics)
- rust-lang/rust#141964 (stdarch submodule update for the stabilization of the runtime detection and intrinsics)
As all of the required tasks have been done (adding the target features to rustc, implementing their runtime detection in std_detect and implementing the associated intrinsics in core_arch), these target features can be stabilized now.
cc `@rust-lang/lang`
cc `@rust-lang/libs-api` for the intrinsics and runtime detection
I don't think anyone else worked on this feature, so no one else to ping, maybe cc `@Amanieu.` I will send the reference pr soon.
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#129121 (Stabilize `tcp_quickack`)
- rust-lang/rust#142192 (De-duplicate f16 & f128 doctest attributes)
- rust-lang/rust#142193 (add tests for pattern binding drop order edge cases)
- rust-lang/rust#142222 (Dont make `ObligationCtxt`s with diagnostics unnecessarily)
- rust-lang/rust#142228 (rustc-dev-guide subtree update)
- rust-lang/rust#142231 (Run `calculate_matrix` job on `master` to cache citool builds)
- rust-lang/rust#142232 (add `Cargo.lock` to CI-rustc allowed list for non-CI env)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
add tests for pattern binding drop order edge cases
This adds tests for rust-lang/rust#142163, rust-lang/rust#142057, and rust-lang/rust#142056. I'm using these tests to help make sure I don't commit breaking changes when implementing match lowering for guard patterns, but I think it makes sense to add them separately. They don't directly have anything to do with guard patterns.
r? `@Nadrieril` or reassign
|
|
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#141751 (Remap compiler vs non-compiler sources differently (bootstrap side))
- rust-lang/rust#142160 (Only allow `bootstrap` cfg in rustc & related)
- rust-lang/rust#142191 (early return in trait detection for non-trait item)
- rust-lang/rust#142211 (Do not checkout GCC submodule for the tidy job)
- rust-lang/rust#142218 (CI: rfl: move job forward to Linux v6.16-rc1)
- rust-lang/rust#142224 (Avoid a gratuitous 10s wait in a stress test)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
early return in trait detection for non-trait item
Fixes rust-lang/rust#135863
|
|
r=workingjubilee
Add (back) `unsupported_calling_conventions` lint to reject more invalid calling conventions
This adds back the `unsupported_calling_conventions` lint that was removed in https://github.com/rust-lang/rust/pull/129935, in order to start the process of dealing with https://github.com/rust-lang/rust/issues/137018. Specifically, we are going for the plan laid out [here](https://github.com/rust-lang/rust/issues/137018#issuecomment-2672118326):
- thiscall, stdcall, fastcall, cdecl should only be accepted on x86-32
- vectorcall should only be accepted on x86-32 and x86-64
The difference to the status quo is that:
- We stop accepting stdcall, fastcall on targets that are windows && non-x86-32 (we already don't accept these on targets that are non-windows && non-x86-32)
- We stop accepting cdecl on targets that are non-x86-32
- (There is no difference for thiscall, this was already a hard error on non-x86-32)
- We stop accepting vectorcall on targets that are windows && non-x86-*
Vectorcall is an unstable ABI so we can just make this a hard error immediately. The others are stable, so we emit the `unsupported_calling_conventions` forward-compat lint. I set up the lint to show up in dependencies via cargo's future-compat report immediately, but we could also make it show up just for the local crate first if that is preferred.
try-job: i686-msvc-1
try-job: x86_64-msvc-1
try-job: test-various
|
|
Rollup of 12 pull requests
Successful merges:
- rust-lang/rust#141803 (Remove rustc's notion of "preferred" alignment AKA `__alignof`)
- rust-lang/rust#142053 (Add new Tier-3 targets: `loongarch32-unknown-none*`)
- rust-lang/rust#142089 (Replace all uses of sysroot_candidates with get_or_default_sysroot)
- rust-lang/rust#142108 (compiler: Add track_caller to AbiMapping::unwrap)
- rust-lang/rust#142132 (`tests/ui`: A New Order [6/N])
- rust-lang/rust#142162 (UnsafePinned: update get() docs and signature to allow shared mutation)
- rust-lang/rust#142171 (`tests/ui`: A New Order [7/N])
- rust-lang/rust#142179 (store `target.min_global_align` as an `Align`)
- rust-lang/rust#142183 (Added test for 30904)
- rust-lang/rust#142194 (Remove all unused feature gates from the compiler)
- rust-lang/rust#142199 (Do not free disk space in the `mingw-check-tidy` job)
- rust-lang/rust#142210 (Run `mingw-check-tidy` on auto builds)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Added test for 30904
Test that was deleted by mistake in this commit
https://github.com/rust-lang/rust/commit/564c78a6981174b32079f576eb6e7f965a13945e#diff-85d65712084246fc61f287664eef63b0b25ba0a5c8b69a4a59a9454b6a3ebac4
The original issue is still open and the problem is not solved (if this is even a problem, but the error is still here at least)
|
|
`tests/ui`: A New Order [7/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
|
|
`tests/ui`: A New Order [6/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? `````@jieyouxu`````
auxiliary tag means some changes in realted auxiliary file for test
|
|
Add new Tier-3 targets: `loongarch32-unknown-none*`
MCP: https://github.com/rust-lang/compiler-team/issues/865
NOTE: LoongArch32 ELF object support is available starting with object v0.37.0.
|
|
In PR 90877 T-lang decided not to remove `intrinsics::pref_align_of`.
However, the intrinsic and its supporting code
1. is a nightly feature, so can be removed at compiler/libs discretion
2. requires considerable effort in the compiler to support, as it
necessarily complicates every single site reasoning about alignment
3. has been justified based on relevance to codegen, but it is only a
requirement for C++ (not C, not Rust) stack frame layout for AIX,
in ways Rust would not consider even with increased C++ interop
4. is only used by rustc to overalign some globals, not correctness
5. can be adequately replaced by other rules for globals, as it mostly
affects alignments for a few types under 16 bytes of alignment
6. has only one clear benefactor: automating C -> Rust translation
for GNU extensions like `__alignof`
7. such code was likely intended to be `alignof` or `_Alignof`,
because the GNU extension is a "false friend" of the C keyword,
which makes the choice to support such a mapping very questionable
8. makes it easy to do incorrect codegen in the compiler by its mere
presence as usual Rust rules of alignment (e.g. `size == align * N`)
do not hold with preferred alignment
The implementation is clearly damaging the code quality of the compiler.
Thus it is within the compiler team's purview to simply rip it out.
If T-lang wishes to have this intrinsic restored for c2rust's benefit,
it would have to use a radically different implementation that somehow
does not cause internal incorrectness.
Until then, remove the intrinsic and its supporting code, as one tool
and an ill-considered GCC extension cannot justify risking correctness.
Because we touch a fair amount of the compiler to change this at all,
and unfortunately the duplication of AbiAndPrefAlign is deep-rooted,
we keep an "AbiAlign" type which we can wean code off later.
|
|
const-eval error: always say in which item the error occurred
I don't see why "is this generic" should make a difference. It may be reasonable to key this on whether the error occurs in a `const fn` that was invoked by a const (making it non-obvious which constant it is) vs inside the body of the const.
r? `@oli-obk`
|
|
Atomic intrinsics : use const generic ordering, part 2
This completes what got started in https://github.com/rust-lang/rust/pull/141507 by using a const generic for the ordering for all intrinsics. It is based on that PR; only the last commit is new.
Blocked on:
- https://github.com/rust-lang/rust/pull/141507
- https://github.com/rust-lang/rust/pull/141687
- https://github.com/rust-lang/stdarch/pull/1811
- https://github.com/rust-lang/rust/pull/141964
r? `@bjorn3`
|
|
|
|
|
|
I couldn't find existing tests that for this behavior, so this should
make sure it doesn't accidentally change.
|
|
|
|
|
|
|
|
also unify error messages that do not seem to have a good reason to be different
|
|
calling conventions
|
|
Many of `std`'s dependency have a dependency on the crates.io
`compiler-builtins` when used with the feature
`rustc-std-workspace-core`. Use a Cargo patch to select the in-tree
version instead.
`compiler-builtins` is also added as a dependency of
`rustc-std-workspace-core` so these crates can remove their crates.io
dependency in the future.
|
|
Remove CollectItemTypesVisitor
I always felt like we were very unnecessarily walking the HIR, let's see if perf agrees
There is lots to ~~improve~~ consolidate further here, as we still have 3 item wfchecks:
* check_item (matching on the hir::ItemKind)
* actually doing trait solver based checks (by using HIR spans)
* lower_item (matching on the hir::ItemKind after loading it again??)
* just ensure_ok-ing a bunch of queries
* check_item_type (matching on DefKind)
* some type based checks, mostly ensure_ok-ing a bunch of queries
fixes rust-lang/rust#121429
|
|
|
|
compiler: Treat ForceWarning as a Warning for diagnostic level
This silences an ICE.
No idea if this is the correct solution though tbh.
Fixes rust-lang/rust#142144
|
|
Treat normalizing consts like normalizing types in deeply normalize
...so that we don't end up putting a top-level normalizes-to goal in the fulfillment context, which ICEs. This basically just models the normalize-const code off of the normalize-ty code above it, which uses an alias-relate goal instead.
Fixes rust-lang/rust#140571
r? lcnr
|
|
Make the `dangerous_implicit_autorefs` lint deny-by-default
I intended for the `dangerous_implicit_autorefs` lint to be deny-by-default, the [T-lang nomination comment](https://github.com/rust-lang/rust/pull/123239#issuecomment-2727551097) even clearly mentioned deny-by-default, but somehow I and other missed that it is only warn-by-default.
I think the lint should still be deny-by-default as the implicit aliasing requirements can be quite dangerous.
In any-case, opening this PR for T-lang awareness.
`@rustbot` label +I-lang-nominated +T-lang
r? `@traviscross`
|
|
Allow `#![doc(test(attr(..)))]` everywhere
This PR adds the ability to specify [`#![doc(test(attr(..)))]`](https://doc.rust-lang.org/nightly/rustdoc/write-documentation/the-doc-attribute.html#testattr) ~~at module level~~ everywhere in addition to allowing it at crate-root.
This is motivated by a recent PR #140323 (by ````@tgross35)```` where we have to duplicate 2 attributes to every single `f16` and `f128` doctests, by allowing `#![doc(test(attr(..)))]` at module level (and everywhere else) we can omit them entirely and just have (in both module):
```rust
#![doc(test(attr(feature(cfg_target_has_reliable_f16_f128))))]
#![doc(test(attr(expect(internal_features))))]
```
Those new attributes are appended to the one found at crate-root or at a previous module. Those "global" attributes are compatible with merged doctests (they already were before).
Given the small addition that this is, I'm proposing to insta-stabilize it, but I can feature-gate it if preferred.
Best reviewed commit by commit.
r? ````@GuillaumeGomez````
|
|
|
|
|
|
|
|
|
|
Update stdarch submodule
Updates the stdarch submodule.
## Merged PRs
- rust-lang/stdarch#1797
- rust-lang/stdarch#1758
- rust-lang/stdarch#1798
- rust-lang/stdarch#1811
- rust-lang/stdarch#1810
- rust-lang/stdarch#1807
- rust-lang/stdarch#1806
- rust-lang/stdarch#1812
- rust-lang/stdarch#1795
- rust-lang/stdarch#1796
- rust-lang/stdarch#1813
- rust-lang/stdarch#1816
- rust-lang/stdarch#1818
- rust-lang/stdarch#1820
- rust-lang/stdarch#1819
r? `@Amanieu`
`@rustbot` label T-libs-api
Closes rust-lang/rust#111137
|
|
also adjust the wording a little so that we don't say "the error occurred here" for two different spans
|
|
This silences an ICE.
|
|
Make cast suggestions verbose
```
error[E0604]: only `u8` can be cast as `char`, not `u32`
--> $DIR/E0604.rs:2:5
|
LL | 1u32 as char;
| ^^^^^^^^^^^^ invalid cast
|
help: try `char::from_u32` instead
|
LL - 1u32 as char;
LL + char::from_u32(1u32);
|
```
```
error[E0620]: cast to unsized type: `&[u8]` as `[char]`
--> $DIR/cast-to-slice.rs:6:5
|
LL | arr as [char];
| ^^^^^^^^^^^^^
|
help: try casting to a reference instead
|
LL | arr as &[char];
| +
```
```
error[E0620]: cast to unsized type: `Box<{integer}>` as `dyn Send`
--> $DIR/cast-to-unsized-trait-object-suggestion.rs:3:5
|
LL | Box::new(1) as dyn Send;
| ^^^^^^^^^^^^^^^^^^^^^^^
|
help: you can cast to a `Box` instead
|
LL | Box::new(1) as Box<dyn Send>;
| ++++ +
```
Part of rust-lang/rust#141973.
|
|
r=compiler-errors
Make obligation cause code suggestions verbose
```
error[E0277]: `()` is not a future
--> $DIR/unnecessary-await.rs:28:10
|
LL | e!().await;
| ^^^^^ `()` is not a future
|
= help: the trait `Future` is not implemented for `()`
= note: () must be a future or must implement `IntoFuture` to be awaited
= note: required for `()` to implement `IntoFuture`
help: remove the `.await`
|
LL - e!().await;
LL + e!();
|
```
```
error[E0277]: the trait bound `String: Copy` is not satisfied
--> $DIR/const-fn-in-vec.rs:1:47
|
LL | static _MAYBE_STRINGS: [Option<String>; 5] = [None; 5];
| ^^^^ the trait `Copy` is not implemented for `String`
|
= note: required for `Option<String>` to implement `Copy`
= note: the `Copy` trait is required because this value will be copied for each element of the array
help: create an inline `const` block
|
LL | static _MAYBE_STRINGS: [Option<String>; 5] = [const { None }; 5];
| +++++++ +
```
Part of rust-lang/rust#141973
|
|
Reduce confusion of some drop order tests
In addition to adhering to normal Rust casing idioms, I ran `rustfmt`.
Closes rust-lang/rust#141604
r? `@jieyouxu`
|
|
Verbose suggestion to make param `const`
```
error[E0747]: type provided when a constant was expected
--> $DIR/invalid-const-arguments.rs:10:19
|
LL | impl<N> Foo for B<N> {}
| ^
|
help: consider changing this type parameter to a const parameter
|
LL - impl<N> Foo for B<N> {}
LL + impl<const N: u8> Foo for B<N> {}
|
```
Part of rust-lang/rust#141973.
|
|
|
|
```
error[E0277]: `()` is not a future
--> $DIR/unnecessary-await.rs:28:10
|
LL | e!().await;
| ^^^^^ `()` is not a future
|
= help: the trait `Future` is not implemented for `()`
= note: () must be a future or must implement `IntoFuture` to be awaited
= note: required for `()` to implement `IntoFuture`
help: remove the `.await`
|
LL - e!().await;
LL + e!();
|
```
```
error[E0277]: the trait bound `String: Copy` is not satisfied
--> $DIR/const-fn-in-vec.rs:1:47
|
LL | static _MAYBE_STRINGS: [Option<String>; 5] = [None; 5];
| ^^^^ the trait `Copy` is not implemented for `String`
|
= note: required for `Option<String>` to implement `Copy`
= note: the `Copy` trait is required because this value will be copied for each element of the array
help: create an inline `const` block
|
LL | static _MAYBE_STRINGS: [Option<String>; 5] = [const { None }; 5];
| +++++++ +
```
|
|
```
error[E0604]: only `u8` can be cast as `char`, not `u32`
--> $DIR/E0604.rs:2:5
|
LL | 1u32 as char;
| ^^^^^^^^^^^^ invalid cast
|
help: try `char::from_u32` instead
|
LL - 1u32 as char;
LL + char::from_u32(1u32);
|
```
```
error[E0620]: cast to unsized type: `&[u8]` as `[char]`
--> $DIR/cast-to-slice.rs:6:5
|
LL | arr as [char];
| ^^^^^^^^^^^^^
|
help: try casting to a reference instead
|
LL | arr as &[char];
| +
```
```
error[E0620]: cast to unsized type: `Box<{integer}>` as `dyn Send`
--> $DIR/cast-to-unsized-trait-object-suggestion.rs:3:5
|
LL | Box::new(1) as dyn Send;
| ^^^^^^^^^^^^^^^^^^^^^^^
|
help: you can cast to a `Box` instead
|
LL | Box::new(1) as Box<dyn Send>;
| ++++ +
```
|
|
|
|
Fast path for stalled obligations on self ty
If we see that the `self` type of a goal is an infer var, then don't try to compute the goal at all, since we know that it'll be forced ambiguous.
This is currently only implemented when there are no opaques in the environment. We could extend it to check that the self type is not related to any already defined opaques via subtyping, but I'll leave that as a follow-up.
---
Also stall coerce and subtype predicates if both of their vars are not resolved to concrete types.
---
~~Also, we don't care if the goal is higher-ranked for the sized and copy/clone fast path.~~ pulling this out into another PR.
r? lcnr
|
|
In addition to adhering to normal Rust casing idioms, I ran `rustfmt`.
|
