| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Before:
let a =
StructWithSomeFields{
field_1: 1,
field_2: 2,
field_3: 3,
field_4: 4,
field_5: 5,
field_6: 6,};
let a = StructWithSomeFields{ field_1: 1, field_2: 2, ..a};
After:
let a =
StructWithSomeFields {
field_1: 1,
field_2: 2,
field_3: 3,
field_4: 4,
field_5: 5,
field_6: 6 };
let a = StructWithSomeFields { field_1: 1, field_2: 2, ..a };
|
|
Reverting because of a performance regression.
This reverts commit d4812c8638173ec163825d56a72a33589483ec4c, reversing
changes made to 5cc60728e7ee10eb2ae5f61f7d412d9805b22f0c.
|
|
Instead of calling new(), we can just use a struct expression directly.
Before:
Placeholder::new(…, …, …, …)
After:
Placeholder {
position: …,
flags: …,
width: …,
precision: …,
}
|
|
Set `target_vendor = "openwrt"` on `mips64-openwrt-linux-musl`
OpenWRT is a Linux distribution for embedded network devices. The target name contains `openwrt`, so we should set `cfg(target_vendor = "openwrt")`.
This is similar to what other Linux distributions do (the only one in-tree is `x86_64-unikraft-linux-musl`, but that sets `target_vendor = "unikraft"`).
Motivation: To make correctly [parsing target names](https://github.com/rust-lang/cc-rs/pull/1413) simpler.
Fixes https://github.com/rust-lang/rust/issues/131165.
CC target maintainer `@Itus-Shield`
|
|
param-env for receiver_is_dispatchable
|
|
rustc_target: Add more RISC-V vector-related features and use zvl*b target features in vector ABI check
Currently, we have only unstable `v` target feature, but RISC-V have more vector-related extensions. The first commit of this PR adds them to unstable `riscv_target_feature`.
- `unaligned-vector-mem`: Has reasonably performant unaligned vector
- [LLVM definition](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L1379)
- Similar to currently unstable `unaligned-scalar-mem` target feature, but for vector instructions.
- `zvfh`: Vector Extension for Half-Precision Floating-Point
- [ISA Manual](https://github.com/riscv/riscv-isa-manual/blob/riscv-isa-release-2336fdc-2025-03-19/src/v-st-ext.adoc#zvfh-vector-extension-for-half-precision-floating-point)
- [LLVM definition](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L668)
- This implies `zvfhmin` and `zfhmin`
- `zvfhmin`: Vector Extension for Minimal Half-Precision Floating-Point
- [ISA Manual](https://github.com/riscv/riscv-isa-manual/blob/riscv-isa-release-2336fdc-2025-03-19/src/v-st-ext.adoc#zvfhmin-vector-extension-for-minimal-half-precision-floating-point)
- [LLVM definition](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L662)
- This implies `zve32f`
- `zve32x`, `zve32f`, `zve64x`, `zve64f`, `zve64d`: Vector Extensions for Embedded Processors
- [ISA Manual](https://github.com/riscv/riscv-isa-manual/blob/riscv-isa-release-2336fdc-2025-03-19/src/v-st-ext.adoc#zve-vector-extensions-for-embedded-processors)
- [LLVM definitions](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L612-L641)
- `zve32x` implies `zvl32b`
- `zve32f` implies `zve32x` and `f`
- `zve64x` implies `zve32x` and `zvl64b`
- `zve64f` implies `zve32f` and `zve64x`
- `zve64d` implies `zve64f` and `d`
- `v` implies `zve64d`
- `zvl*b`: Minimum Vector Length Standard Extensions
- [ISA Manual](https://github.com/riscv/riscv-isa-manual/blob/riscv-isa-release-2336fdc-2025-03-19/src/v-st-ext.adoc#zvl-minimum-vector-length-standard-extensions)
- [LLVM definitions](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L600-L610)
- `zvl{N}b` implies `zvl{N>>1}b`
- `v` implies `zvl128b`
- Vector Cryptography and Bit-manipulation Extensions
- [ISA Manual](https://github.com/riscv/riscv-isa-manual/blob/riscv-isa-release-2336fdc-2025-03-19/src/vector-crypto.adoc)
- [LLVM definitions](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L679-L807)
- `zvkb`: Vector Bit-manipulation used in Cryptography
- This implies `zve32x`
- `zvbb`: Vector basic bit-manipulation instructions
- This implies `zvkb`
- `zvbc`: Vector Carryless Multiplication
- This implies `zve64x`
- `zvkg`: Vector GCM instructions for Cryptography
- This implies `zve32x`
- `zvkned`: Vector AES Encryption & Decryption (Single Round)
- This implies `zve32x`
- `zvknha`: Vector SHA-2 (SHA-256 only))
- This implies `zve32x`
- `zvknhb`: Vector SHA-2 (SHA-256 and SHA-512)
- This implies `zve64x`
- This is superset of `zvknha`, but doesn't imply that feature at least in LLVM
- `zvksed`: SM4 Block Cipher Instructions
- This implies `zve32x`
- `zvksh`: SM3 Hash Function Instructions
- This implies `zve32x`
- `zvkt`: Vector Data-Independent Execution Latency
- Similar to already stabilized scalar cryptography extension `zkt`.
- `zvkn`: Shorthand for 'Zvkned', 'Zvknhb', 'Zvkb', and 'Zvkt'
- Similar to already stabilized scalar cryptography extension `zkn`.
- `zvknc`: Shorthand for 'Zvkn' and 'Zvbc'
- `zvkng`: shorthand for 'Zvkn' and 'Zvkg'
- `zvks`: shorthand for 'Zvksed', 'Zvksh', 'Zvkb', and 'Zvkt'
- Similar to already stabilized scalar cryptography extension `zks`.
- `zvksc`: shorthand for 'Zvks' and 'Zvbc'
- `zvksg`: shorthand for 'Zvks' and 'Zvkg'
Also, our vector ABI check wants `zvl*b` target features, the second commit of this PR updates vector ABI check to use them.
https://github.com/rust-lang/rust/blob/4e2b096ed6c8a1400624a54f6c4fd0c0ce48a579/compiler/rustc_target/src/target_features.rs#L707-L708
---
r? `@Amanieu`
`@rustbot` label +O-riscv +A-target-feature
|
|
|
|
`BackendRepr::is_signed`: comment why this may panics
Was wondering why this method could panics while the others couldn't, so quote PR #70189.
|
|
Fix `uclibc` LLVM target triples
`uclibc` is not an environment understood by LLVM, it is only a concept in Clang that can be selected with `-muclibc` (it affects which dynamic linker is passed to the static linker's `-dynamic-linker` flag).
In fact, using `uclibcgnueabi`/`uclibc` is actively harmful, as it prevents LLVM from seeing that the target is gnu-like; we should use `gnueabi`/`gnu` directly instead.
Motivation: To make it easier to verify that [`cc-rs`' conversion from `rustc` to Clang/LLVM triples](https://github.com/rust-lang/cc-rs/issues/1431) is correct.
**There are no target maintainers for these targets.** So I'll CC ``@lancethepants`` and ``@skrap`` who maintain the related `armv7-unknown-linux-uclibceabi` and `armv7-unknown-linux-uclibceabihf` (both of which already pass `-gnu` instead of `-uclibc`) in case they have any insights.
r? jieyouxu
|
|
perform less decoding if it has the same syntax context
Following this [comment](https://github.com/rust-lang/rust/pull/127279#issuecomment-2210376603)
r? `@petrochenkov`
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #138692 (Reject `{true,false}` as revision names)
- #138757 (wasm: increase default thread stack size to 1 MB)
- #138988 (Change the syntax of the internal `weak!` macro)
- #139056 (use `try_fold` instead of `fold`)
- #139057 (use `slice::contains` where applicable)
- #139086 (Various cleanup in ExprUseVisitor)
- #139097 (Add more tests for pin!().)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
r=compiler-errors
Various cleanup in ExprUseVisitor
These are the non-behavior-changing commits from #138961.
|
|
use `slice::contains` where applicable
Applies the [`manual_contains`](https://rust-lang.github.io/rust-clippy/master/index.html#manual_contains) clippy lint, plus some small drive-bys.
|
|
use `try_fold` instead of `fold`
Small cleanup, applies the [`manual_try_fold`](https://rust-lang.github.io/rust-clippy/master/index.html#manual_try_fold) clippy lint.
|
|
Remove `terminating_scopes` hash set.
Instead of inserting and checking ids in a hashset, we can just pass a boolean as argument.
For example:
```diff
- visitor.terminating_scopes.insert(arm.hir_id.local_id);
- visitor.enter_node_scope_with_dtor(arm.hir_id.local_id);
+ visitor.enter_node_scope_with_dtor(arm.hir_id.local_id, true);
```
|
|
|
|
|
|
Do not treat lifetimes from parent items as influencing child items
```rust
struct A;
impl Bar<'static> for A {
const STATIC: &str = "";
// ^ no future incompat warning
}
```
has no future incompat warning, because there is no ambiguity. But
```rust
struct C;
impl Bar<'_> for C {
// ^^ this lifeimte
const STATIC: &'static str = {
struct B;
impl Bar<'static> for B {
const STATIC: &str = "";
// causes ^ to emit a future incompat warning
}
""
};
}
```
had one before this PR, because the impl for `B` (which is just a copy of `A`) thought it was influenced by a lifetime on the impl for `C`.
I double checked all other `lifetime_ribs` iterations and all of them do check for `Item` boundaries. This feels very fragile tho, and ~~I think we should do not even be able to see ribs from parent items, but that's a different refactoring that I'd rather not do at the same time as a bugfix~~. EDIT: ah nevermind, this is needed for improving diagnostics like "use of undeclared lifetime" being "can't use generic parameters from outer item" instead.
r? `@compiler-errors`
|
|
Fix TAIT & ATPIT feature gating in the presence of anon consts
Fixes #139055 (https://github.com/rust-lang/rust/issues/119924#issuecomment-1928659690).
r? oli-obk or anybody else
|
|
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #137889 (update outdated doc with new example)
- #138104 (Greatly simplify doctest parsing and information extraction)
- #138678 (rustc_resolve: fix instability in lib.rmeta contents)
- #138986 (feat(config): Add ChangeId enum for suppressing warnings)
- #139038 (Update target maintainers for thumb targets to reflect new REWG Arm team name)
- #139045 (bootstrap: update `test_find` test)
- #139047 (Remove ScopeDepth)
Failed merges:
- #139044 (bootstrap: Avoid cloning `change-id` list)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Remove ScopeDepth
The scope depth was tracked, but never seemed to be used for anything.
Every single place that used `(Scope, ScopeDepth)`, matched it on `(p, _)`.
|
|
rustc_resolve: fix instability in lib.rmeta contents
rust-lang/rust@23032f31c91f2 accidentally introduced some nondeterminism in the ordering of lib.rmeta files, which we caught in our bazel-based builds only recently due to being further behind than normal. In my testing, this fixes the issue.
|
|
update outdated doc with new example
update the illegal definition example because we can compile `struct Ref<'a, T> { x: &'a T }` ([play](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=2eb2f8800d423c316b545c864623ae16))
|
|
Avoid wrapping constant allocations in packed structs when not necessary
This way LLVM will set the string merging flag if the alloc is a nul terminated string, reducing binary sizes.
try-job: armhf-gnu
|
|
|
|
This way LLVM will set the string merging flag if the alloc is a nul
terminated string, reducing binary sizes.
|
|
|
|
The scope depth was tracked, but never actually used for anything.
|
|
Rollup of 6 pull requests
Successful merges:
- #138720 (Specify a concrete stack size in channel tests)
- #139010 (Improve `xcrun` error handling)
- #139021 (std: get rid of pre-Vista fallback code)
- #139025 (Do not trim paths in MIR validator)
- #139026 (Use `abs_diff` where applicable)
- #139030 (saethlin goes on vacation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove `kw::Empty` uses from `hir::Lifetime::ident`
`hir::Lifetime::ident` is sometimes set to `kw::Empty` and it's really confusing. This PR stops that. Helps with #137978.
r? `@lcnr`
|
|
It's an old (2017 or earlier) type that describes a `self` receiver.
It's only used in `rustc_hir_analysis` for two error messages, and much
of the complexity isn't used. I suspect it used to be used for more
things.
This commit removes it, and moves a greatly simplified version of the
`determine` method into `rustc_hir_analysis`, renamed as
`get_self_string`. The big comment on the method is removed because it
no longer seems relevant.
|
|
Use `abs_diff` where applicable
Very small cleanup, dogfooding a [new clippy lint](https://github.com/rust-lang/rust-clippy/pull/14482) I'm trying to add
|
|
Do not trim paths in MIR validator
From my inline comment:
```
// The type checker formats a bunch of strings with type names in it, but these strings
// are not always going to be encountered on the error path since the inliner also uses
// the validator, and there are certain kinds of inlining (even for valid code) that
// can cause validation errors (mostly around where clauses and rigid projections).
```
Fixes https://github.com/rust-lang/rust/issues/138979
r? `@jieyouxu`
|
|
Improve `xcrun` error handling
The compiler invokes `xcrun` on macOS when linking Apple targets, to find the Xcode SDK which contain all the necessary linker stubs. The error messages that `xcrun` outputs aren't always that great though, so this PR tries to improve that by providing extra context when an error occurs.
Fixes https://github.com/rust-lang/rust/issues/56829.
Fixes https://github.com/rust-lang/rust/issues/84534.
Part of https://github.com/rust-lang/rust/issues/129432.
See also the alternative https://github.com/rust-lang/rust/pull/131433.
Tested on:
- `x86_64-apple-darwin`, MacBook Pro running Mac OS X 10.12.6
- With no tooling installed
- With Xcode 9.2
- With Xcode 9.2 Commandline Tools
- `aarch64-apple-darwin`, MacBook M2 Pro running macOS 14.7.4
- With Xcode 13.4.1
- With Xcode 16.2
- Inside `nix-shell -p xcbuild` (nixpkgs' `xcrun` shim)
- `aarch64-apple-darwin`, VM running macOS 15.3.1
- With no tooling installed
- With Xcode 16.2 Commandline Tools
``@rustbot`` label O-apple
r? compiler
CC ``@BlackHoleFox`` ``@thomcc``
|
|
`hir::Lifetime::ident` currently sometimes uses `kw::Empty` for elided
lifetimes and sometimes uses `kw::UnderscoreLifetime`, and the
distinction is used when creating some error suggestions, e.g. in
`Lifetime::suggestion` and `ImplicitLifetimeFinder::visit_ty`. I found
this *really* confusing, and it took me a while to understand what was
going on.
This commit replaces all uses of `kw::Empty` in `hir::Lifetime::ident`
with `kw::UnderscoreLifetime`. It adds a new field
`hir::Lifetime::is_path_anon` that mostly replaces the old
empty/underscore distinction and makes things much clearer.
Some other notable changes:
- Adds a big comment to `Lifetime` talking about permissable field
values.
- Adds some assertions in `new_named_lifetime` about what ident values
are permissible for the different `LifetimeRes` values.
- Adds a `Lifetime::new` constructor that does some checking to make
sure the `is_elided` and `is_anonymous` states are valid.
- `add_static_impl_trait_suggestion` now looks at `Lifetime::res`
instead of the ident when creating the suggestion. This is the one
case where `is_path_anon` doesn't replace the old empty/underscore
distinction.
- A couple of minor pretty-printing improvements.
|
|
It has no effect on anything in the test suite.
This means it can also be rewritten as a neater pairwise `match`.
|
|
They both are only used in `Lifetime::suggestion`. This commit inlines
and removes them.
|
|
|
|
|
|
|
