| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Update test for LLVM 20's new vector splat syntax
that was introduced in https://github.com/llvm/llvm-project/pull/112548
|
|
core: move intrinsics.rs into intrinsics folder
This makes the rustbot notification we have set up for this folder in `triagebot.toml` actually work. Also IMO it makes more sense to have it all in one folder.
|
|
[StableMIR] API to retrieve definitions from crates
Add functions to retrieve function definitions and static items from all crates (local and external).
For external crates, we're still missing items from trait implementation and primitives.
r? ````@compiler-errors:```` Do you know what is the best way to retrieve the associated items for primitives and trait implementations for external crates? Thanks!
|
|
Fix #131977 parens mangled in shared mut static lint suggestion
Resolves #131977 for static mut references after discussion with
Esteban & Jieyou on [t-compiler/help](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/linting.20with.20parens.20in.20the.20HIR).
This doesn't do anything to change the underlying issue if there are other expressions that generate lint suggestions which need to be applied within parentheses.
|
|
Add `{ignore,needs}-{rustc,std}-debug-assertions` directive support
Add `{ignore,needs}-{rustc,std}-debug-assertions` compiletest directives and retire the old `{ignore,only}-debug` directives. The old `{ignore,only}-debug` directives were ambiguous because you could have std built with debug assertions but rustc not built with debug assertions or vice versa. If we want to support the use case of controlling test run based on if rustc was built with debug assertions, then having `{ignore,only}-debug` will be very confusing.
cc ````@matthiaskrgr````
Closes #123987.
r? bootstrap (or compiler tbh)
|
|
Add functions to retrieve function definitions and static items from
all crates (local and external).
For external crates, add a query to retrieve the number of defs in a
foreign crate.
|
|
Basic inline assembly support for SPARC and SPARC64
This implements asm_experimental_arch (tracking issue https://github.com/rust-lang/rust/issues/93335) for SPARC and SPARC64.
This PR includes:
- General-purpose registers `r[0-31]` (`reg` register class, LLVM/GCC constraint `r`)
Supported types: i8, i16, i32, i64 (SPARC64-only)
Aliases: `g[0-7]` (`r[0-7]`), `o[0-7]` (`r[8-15]`), `l[0-7]` (`r[16-23]`), `i[0-7]` (`r[24-31]`)
- `y` register (clobber-only, needed for clobber_abi)
- preserves_flags: Integer condition codes (`icc`, `xcc`) and floating-point condition codes (`fcc*`)
The following are *not* included:
- 64-bit integer support on SPARC-V8+'s global or out registers (`g[0-7]`, `o[0-7]`): GCC's `h` constraint (it seems that there is no corresponding constraint in LLVM?)
- Floating-point registers (LLVM/GCC constraint `e`/`f`):
I initially tried to implement this, but postponed it for now because there seemed to be several parts in LLVM that behaved differently than in the LangRef's description.
- clobber_abi: Support for floating-point registers is needed.
Refs:
- LLVM
- Reserved registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/SparcRegisterInfo.cpp#L52
- Register definitions https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/Sparc/SparcRegisterInfo.td
- Supported constraints https://llvm.org/docs/LangRef.html#supported-constraint-code-list
- GCC
- Reserved registers https://github.com/gcc-mirror/gcc/blob/63b6967b06b5387821c4e5f2c113da6aaeeae2b7/gcc/config/sparc/sparc.h#L633-L658
- Supported constraints https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html
- SPARC ISA/ABI
- (64-bit ISA) The SPARC Architecture Manual, Version 9
(32-bit ISA) The SPARC Architecture Manual, Version 8
(64-bit ABI) System V Application Binary Interface SPARC Version 9 Processor Supplement, Rev 1.35
(32-bit ABI) System V Application Binary Interface SPARC Processor Supplement, Third Edition
The above docs can be downloaded from https://sparc.org/technical-documents
- (32-bit V8+ ABI) The V8+ Technical Specification
https://temlib.org/pub/SparcStation/Standards/V8plus.pdf
cc `@thejpster` (sparc-unknown-none-elf target maintainer)
(AFAIK, other sparc/sprac64 targets don't have target maintainers)
r? `@Amanieu`
`@rustbot` label +O-SPARC +A-inline-assembly
|
|
that was introduced in https://github.com/llvm/llvm-project/pull/112548
|
|
|
|
|
|
Add --diagnostic-width to some tests failing after 1a0c5021838
Otherwise the tests would fail depending on the execution environment.
|
|
more crash tests
r? `@jieyouxu`
|
|
|
|
Otherwise the tests would fail depending on the execution environment.
|
|
Rollup of 3 pull requests
Successful merges:
- #132617 (Fix an extra newline in rendered std doc)
- #132698 (Remove unneeded fields in `scrape_examples::FindCalls`)
- #132700 (add note not to re-report crashes from `crashes` tests)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
add note not to re-report crashes from `crashes` tests
for reasons... :sweat_smile:
r? `@fmease`
|
|
|
|
|
|
Suggest swapping LHS and RHS when RHS impls `PartialEq<lhs_ty>`
Closes: #130495
r? `@fee1-dead`
|
|
Tweak E0320 overflow error wording
Surround type with backticks as we should in every error.
|
|
Rollup of 5 pull requests
Successful merges:
- #131261 (Stabilize `UnsafeCell::from_mut`)
- #131405 (bootstrap/codegen_ssa: ship llvm-strip and use it for -Cstrip)
- #132077 (Add a new `wide-arithmetic` feature for WebAssembly)
- #132562 (Remove the `wasm32-wasi` target from rustc)
- #132660 (Remove unused errs.rs file)
Failed merges:
- #131721 (Add new unstable feature `const_eq_ignore_ascii_case`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Remove the `wasm32-wasi` target from rustc
This commit is the final step in the journey of renaming the historical `wasm32-wasi` target in the Rust compiler to `wasm32-wasip1`. Various steps in this journey so far have been:
* 2023-04-03: rust-lang/compiler-team#607 - initial proposal for this rename
* 2024-11-27: rust-lang/compiler-team#695 - amended schedule/procedure for rename
* 2024-01-29: rust-lang/rust#120468 - initial introduction of `wasm32-wasip1`
* 2024-06-18: rust-lang/rust#126662 - warn on usage of `wasm32-wasi`
* 2024-11-08: this PR - remove the `wasm32-wasi` target
The full transition schedule is in [this comment][comment] and is summarized with:
* 2024-05-02: Rust 1.78 released with `wasm32-wasip1` target
* 2024-09-05: Rust 1.81 released warning on usage of `wasm32-wasi`
* 2025-01-09: Rust 1.84 to be released without the `wasm32-wasi` target
This means that support on stable for the replacement target of `wasm32-wasip1` has currently been available for 6 months. Users have already seen warnings on stable for 2 months about usage of `wasm32-wasi` and stable users have another 2 months of warnings before the target is removed from stable.
This commit is intended to be the final step in this transition so the source tree should no longer mention `wasm32-wasi` except in historical reference to the older name of the `wasm32-wasip1` target.
[comment]: https://github.com/rust-lang/rust/pull/120468#issuecomment-1977878747
|
|
Add a new `wide-arithmetic` feature for WebAssembly
This commit adds a new rustc target feature named `wide-arithmetic` for WebAssembly targets. This corresponds to the [wide-arithmetic] proposal for WebAssembly which adds new instructions catered towards accelerating integer arithmetic larger than 64-bits. This proposal to WebAssembly is not standard yet so this new feature is flagged as an unstable target feature. Additionally Rust's LLVM version doesn't support this new feature yet since support will first be added in LLVM 20, so the feature filtering logic for LLVM is updated to handle this.
I'll also note that I'm not currently planning to add wasm-specific intrinsics to `std::arch::wasm32` at this time. The currently proposed instructions are all accessible through `i128` or `u128`-based operations which Rust already supports, so intrinsic shouldn't be necessary to get access to these new instructions.
[wide-arithmetic]: https://github.com/WebAssembly/wide-arithmetic
|
|
Surrount type with backticks as we should in every error.
|
|
add const_eval_select macro to reduce redundancy
I played around a bit with a macro to make const_eval_select invocations look a bit nicer and avoid repeating the argument lists. Here's what I got. What do you think?
I didn't apply this everywhere yet because I wanted to gather feedback first.
The second commit moves the macros from https://github.com/rust-lang/rust/pull/132542 into a more sensible place. It didn't seem worth its own PR and would conflict with this PR if done separately.
Cc ``@oli-obk`` ``@saethlin`` ``@tgross35``
try-job: dist-aarch64-msvc
|
|
Properly suggest `E::assoc` when we encounter `E::Variant::assoc`
Use the right span when encountering an enum variant followed by an associated item so we don't lose the associated item in the resulting code.
Do not suggest the thing twice, once as a removal of the associated item and a second time as a typo suggestion.
|
|
Suggest fixing typos and let bindings at the same time
Fixes #132483
Currently, a suggestion for adding a let binding won't be shown if we suggest fixing a typo. This changes that behavior to always show both, if possible. Essentially, this turns the suggestion from
```rust
error[E0425]: cannot find value `x2` in this scope
--> src/main.rs:4:5
|
4 | x2 = 2;
| ^^ help: a local variable with a similar name exists: `x1`
For more information about this error, try `rustc --explain E0425`.
```
to
```rust
error[E0425]: cannot find value `x2` in this scope
--> src/main.rs:4:5
|
4 | x2 = 2;
| ^^
|
help: a local variable with a similar name exists
|
4 | x1 = 2;
| ~~
help: you might have meant to introduce a new binding
|
4 | let x2 = 2;
| +++
For more information about this error, try `rustc --explain E0425`.
```
for the following code:
```rust
fn main() {
let x1 = 1;
x2 = 2;
}
```
The original behavior only shows the suggestion for a let binding if a typo suggestion wasn't already displayed. However, this falls apart in the cases like the one above where we have multiple similar variables. I don't think it makes sense to hide this suggestion if there's a similar variable, since that defeats the purpose of this suggestion in that case (it's meant to help those coming from languages like Python).
|
|
rustc_codegen_llvm: Add a new 'pc' option to branch-protection
Add a new 'pc' option to -Z branch-protection for aarch64 that enables the use of PC as a diversifier in PAC branch protection code.
When the pauth-lr target feature is enabled in combination with -Z branch-protection=pac-ret,pc, the new 9.5-a instructions (pacibsppc, retaasppc, etc) will be generated.
|
|
mark some target features as 'forbidden' so they cannot be (un)set with -Ctarget-feature
The context for this is https://github.com/rust-lang/rust/issues/116344: some target features change the way floats are passed between functions. Changing those target features is unsound as code compiled for the same target may now use different ABIs.
So this introduces a new concept of "forbidden" target features (on top of the existing "stable " and "unstable" categories), and makes it a hard error to (un)set such a target feature. For now, the x86 and ARM feature `soft-float` is on that list. We'll have to make some effort to collect more relevant features, and similar features from other targets, but that can happen after the basic infrastructure for this landed. (These features are being collected in https://github.com/rust-lang/rust/issues/131799.)
I've made this a warning for now to give people some time to speak up if this would break something.
MCP: https://github.com/rust-lang/compiler-team/issues/780
|
|
Remove unnecessary pub enum glob-imports from `rustc_middle::ty`
We used to have an idiom in the compiler where we'd prefix or suffix all the variants of an enum, for example `BoundRegionKind`, with something like `Br`, and then *glob-import* that enum variant directly.
`@noratrieb` brought this up, and I think that it's easier to read when we just use the normal style `EnumName::Variant`.
This PR is a bit large, but it's just naming.
The only somewhat opinionated change that this PR does is rename `BorrowKind::Imm` to `BorrowKind::Immutable` and same for the other variants. I think these enums are used sparingly enough that the extra length is fine.
r? `@noratrieb` or reassign
|
|
also move internal const_panic helpers to a better location
|
|
Rollup of 11 pull requests
Successful merges:
- #131153 (Improve duplicate derive Copy/Clone diagnostics)
- #132025 (fix suggestion for diagnostic error E0027)
- #132303 (More tests for non-exhaustive C-like enums in FFI)
- #132492 (remove support for extern-block const intrinsics)
- #132587 (Revert "Avoid nested replacement ranges" from #129346.)
- #132596 ([rustdoc] Fix `--show-coverage` when JSON output format is used)
- #132598 (Clippy: Move some attribute lints to be early pass (post expansion))
- #132601 (Update books)
- #132606 (Improve example of `impl Pattern for &[char]`)
- #132608 (document `type_implements_trait`)
- #132609 (docs: fix grammar in doc comment at unix/process.rs)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
[rustdoc] Fix `--show-coverage` when JSON output format is used
I realized while looking on the docs.rs page of the `sysinfo` crate that the coverage numbers displayed were wrong:
I realized that it was because `--show-coverage --output-format=json` was relying on the same logic as the JSON output for the doc generation whereas it should not. I fixed it by changing the API for querying `is_json` a bit.
The underlying issue is that JSON output format is stripping reexports of items from private modules.
r? ``@notriddle``
|
|
remove support for extern-block const intrinsics
This converts all const-callable intrinsics into the "new" form of a regular `fn` with `#[rustc_intrinsic]` attribute. That simplifies some of the logic since those functions can be marked `const fn` like regular functions, so intrinsics no longer need a special case to be considered const-callable at all.
I also added a new attribute `#[rustc_const_stable_intrinsic]` to mark an intrinsic as being ready to be exposed on stable. Previously we used the `#[rustc_const_stable_indirect]` attribute for that, but that attribute had a dual role -- when used on a regular function, it is an entirely safe marker to make this function part of recursive const stability, but on an intrinsic it is a trusted marker requiring special care. It's not great for the same attribute to be sometimes fully checked and safe, and sometimes trusted and requiring special care, so I split this into two attributes.
This also fixes https://github.com/rust-lang/rust/issues/122652 by accepting intrinsics as const-stable if they have a fallback body that is recursively const-stable.
The library changes are best reviewed with whitespace hidden.
r? `@compiler-errors`
|
|
More tests for non-exhaustive C-like enums in FFI
Add a few more tests for the `improper_ctypes` lint as found with the [varnish-rs](https://github.com/gquintard/varnish-rs) project.
This follows up on #116831, fixed in #116863 by ``@workingjubilee`` - I have been seeing these fail with the bindgen-generated non-exhaustive enums inside other structs. Seems the issue does not exist in the primary branch, so this PR just makes sure more cases are covered for the future.
|
|
fix suggestion for diagnostic error E0027
Closes #132008
|
|
Improve duplicate derive Copy/Clone diagnostics
Improve duplicate derive Copy/Clone diagnostics.
Closes #131083
|
|
Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly
This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335.
This basically does a similar thing I did in https://github.com/rust-lang/rust/pull/130630 to implement `clobber_abi` for s390x, but for powerpc/powerpc64/powerpc64le.
- This also supports vector registers (as `vreg`) as clobber-only, which need to support clobbering of them to implement `clobber_abi`.
- `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `altivec` target feature is enabled, but `core::arch::{powerpc,powerpc64}` vector types, `#[repr(simd)]`, and `core::simd` are all unstable, so the fact that this is currently a clobber-only should not be considered a blocker of clobber_abi implementation or stabilization. So I have not implemented it in this PR.
- See https://github.com/rust-lang/rust/pull/131551 (which is based on this PR) for a PR to implement this.
- (I'm not sticking to whether that PR should be a separate PR or part of this PR, so I can merge that PR into this PR if needed.)
Refs:
- PPC32 SysV: Section "Function Calling Sequence" in [System V Application Binary Interface PowerPC Processor Supplement](https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf)
- PPC64 ELFv1: Section 3.2 "Function Calling Sequence" in [64-bit PowerPC ELF Application Binary Interface Supplement](https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-CALL)
- PPC64 ELFv2: Section 2.2 "Function Calling Sequence" in [64-Bit ELF V2 ABI Specification](https://openpowerfoundation.org/specifications/64bitelfabi/)
- AIX: [Register usage and conventions](https://www.ibm.com/docs/en/aix/7.3?topic=overview-register-usage-conventions), [Special registers in the PowerPC®](https://www.ibm.com/docs/en/aix/7.3?topic=overview-special-registers-in-powerpc), [AIX vector programming](https://www.ibm.com/docs/en/aix/7.3?topic=concepts-aix-vector-programming)
- Register definition in LLVM: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/PowerPC/PPCRegisterInfo.td#L189
If I understand the above four ABI documentations correctly, except for the PPC32 SysV's VR (Vector Registers) and 32-bit AIX (currently not supported by rustc)'s r13, there does not appear to be important differences in terms of implementing `clobber_abi`:
- The above four ABIs are consistent about FPR (0-13: volatile, 14-31: nonvolatile), CR (0-1,5-7: volatile, 2-4: nonvolatile), XER (volatile), and CTR (volatile).
- As for GPR, only the registers we are treating as reserved are slightly different
- r0, r3-r12 are volatile
- r1(sp, reserved), r14-31 are nonvolatile
- r2(reserved) is TOC pointer in PPC64 ELF/AIX, system-reserved register in PPC32 SysV (AFAIK used as thread pointer in Linux/BSDs)
- r13(reserved for non-32-bit-AIX) is thread pointer in PPC64 ELF, small data area pointer register in PPC32 SysV, "reserved under 64-bit environment; not restored across system calls[^r13]" in AIX)
- As for FPSCR, volatile in PPC64 ELFv1/AIX, some fields are volatile only in certain situations (rest are volatile) in PPC32 SysV/PPC64 ELFv2.
- As for VR (Vector Registers), it is not mentioned in PPC32 SysV, v0-v19 are volatile in both in PPC64 ELF/AIX, v20-v31 are nonvolatile in PPC64 ELF, reserved or nonvolatile depending on the ABI ([vec-extabi vs vec-default in LLVM](https://reviews.llvm.org/D89684), we are [using vec-extabi](https://github.com/rust-lang/rust/pull/131341#discussion_r1797693299)) in AIX:
> When the default Vector enabled mode is used, these registers are reserved and must not be used.
> In the extended ABI vector enabled mode, these registers are nonvolatile and their values are preserved across function calls
I left [FIXME comment about PPC32 SysV](https://github.com/rust-lang/rust/pull/131341#discussion_r1790496095) and added ABI check for AIX.
- As for VRSAVE, it is not mentioned in PPC32 SysV, nonvolatile in PPC64 ELFv1, reserved in PPC64 ELFv2/AIX
- As for VSCR, it is not mentioned in PPC32 SysV/PPC64 ELFv1, some fields are volatile only in certain situations (rest are volatile) in PPC64 ELFv2, volatile in AIX
We are currently treating r1-r2, r13 (non-32-bit-AIX), r29-r31, LR, CTR, and VRSAVE as reserved.
We are currently not processing anything about FPSCR and VSCR, but I feel those are things that should be processed by `preserves_flags` rather than `clobber_abi` if we need to do something about them. (However, PPCRegisterInfo.td in LLVM does not seem to define anything about them.)
Replaces #111335 and #124279
cc `@ecnelises` `@bzEq` `@lu-zero`
r? `@Amanieu`
`@rustbot` label +O-PowerPC +A-inline-assembly
[^r13]: callee-saved, according to [LLVM](https://github.com/llvm/llvm-project/blob/6a6af0246bd2d68291582e9aefc0543e5c6102fe/llvm/lib/Target/PowerPC/PPCCallingConv.td#L322) and [GCC](https://github.com/gcc-mirror/gcc/blob/a9173a50e7e346a218323916e4d3add8552529ae/gcc/config/rs6000/rs6000.h#L859).
|
|
|
|
on stable
|
|
|
|
|
|
|
|
For now, this is just a warning, but should become a hard error in the future
|
|
Suggest creating unary tuples when types don't match a trait
When you want to have a variadic function, a common workaround to implement this is to create a trait and then implement that trait for various tuples. For example in `pyo3` there exists
```rust
/// Calls the object with only positional arguments.
pub fn call1(&self, args: impl IntoPy<Py<PyTuple>>) -> PyResult<&PyAny> {
...
}
```
with various impls like
```rust
impl<A: IntoPy<PyObject> IntoPy<Py<PyAny>> for (A,)
impl<A: IntoPy<PyObject, B: IntoPy<PyObject> IntoPy<Py<PyAny>> for (A, B)
... etc
```
This means that if you want to call the method with a single item you have to create a unary tuple, like `(x,)`, rather than just `x`.
This PR implements a suggestion to do that, if applicable.
|
|
find the generic container rather than simply looking up for the assoc with const arg
Fixes #132534
This issue is caused by mismatched generic parameters. Previously, it tried to find `T` in `trait X`, but after this change, it will find `T` in `fn a`.
r? `@compiler-errors` as this assertion was introduced by you.
|
|
r=compiler-errors
Use backticks instead of single quotes for library feature names in diagnostics
This PR changes the text of library feature errors for using unstable or body-unstable items. Displaying library feature names in backticks is consistent with other diagnostics (e.g. those from `rustc_passes`) and with the `reason`s on unstable attributes in the library. Additionally, this simplifies diagnostics when supporting multiple unstable attributes on items (see #131824) since `DiagSymbolList` also displays symbols using backticks.
|
|
|
|
Register `~const` preds for `Deref` adjustments in HIR typeck
This doesn't *do* anything yet, since `Deref` and `DerefMut` aren't constified, and we explicitly don't error on calling non-const trait methods in HIR yet -- presumably that will wait until std is re-constified. But I'm confident this logic is correct, and this (afaict?) is the only major hole left in enforcing `~const` in HIR typeck.
r? fee1-dead
|
|
|
