| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Remove fragile equal-pointers-unequal tests.
Same as https://github.com/rust-lang/rust/pull/139176
---
These tests were added in #127003
These tests stop working when I change implementation details of format_args!(). These tests shouldn't rely on such implementation details.
Do these tests test anything that isn't already covered by other tests? If so, they should be expressed in a less fragile way that doesn't rely on internal details of format_args!().
cc `@GrigorenkoPV,` author of these tests.
|
|
organize and extend forbidden target feature tests
In particular this adds some loongarch tests for https://github.com/rust-lang/rust/pull/135015, Cc `@heiher`
Seems like the tests change so much git does not detect the renames; a commit-by-commit review should help.
try-job: `x86_64-gnu-llvm-20-*`
|
|
resolve: Support imports of associated types and glob imports from traits
Follow up to https://github.com/rust-lang/rust/pull/134754, part of https://github.com/rust-lang/rust/issues/134691.
This PR also closes https://github.com/rust-lang/rust/issues/138711 now.
Prohibiting `use Trait::AssocType;` at name resolution stage doesn't make sense, the name itself is perfectly resolveable.
It's a type checker's problem that the necessary generic args are not passed when the imported `AssocType` is used, so an error should be reported there.
And since we can import associated trait items now, glob imports from traits can also be allowed.
|
|
Improve hir pretty printing
It's currently pretty bad, so a few small improvements can make a big difference.
r? `@dtolnay`
|
|
Add regression test for #140545
Closes #140545
I am not very knowledgable about the typesystem internals, so I couldn't come up with a good name for the test. But I'm happy to move it to a more appropriate place if there is one (`tests/ui/impl-trait/non-defining-uses` maybe?)
r? types (or reroll as appropriate if this is not actually a T-types issue; i'm clueless)
|
|
r=compiler-errors
Emit user type annotations for free consts in pattern position
This previously wasnt done because free consts couldn't have any generic parameters that need to be preserved for borrowck. This is no longer the case with `feature(generic_const_items)`
r? fmease
|
|
linker: Quote symbol names in .def files
To support weird symbol names, including dots in particular.
cc [#134767](https://github.com/rust-lang/rust/pull/134767#issuecomment-2839397610)
|
|
|
|
|
|
|
|
One of the boxes isn't closed, and this causes everything after it to be
over-indented.
|
|
for #140545
|
|
Add regression test for 133065
closes: #133065
|
|
r=workingjubilee
Stabilize `select_unpredictable`
FCP completed in tracking issue #133962.
|
|
interpret: better error message for out-of-bounds pointer arithmetic and accesses
Fixes https://github.com/rust-lang/rust/issues/93881
r? `@saethlin`
|
|
Use select in projection lookup in `report_projection_error`
Using `for_each_relevant_impl` doesn't actually select the correct impl; we can use `select` here to actually get the correct impl with certainty. Follow-up to https://github.com/rust-lang/rust/pull/140278.
r? oli-obk
|
|
Rollup of 12 pull requests
Successful merges:
- #134034 (handle paren in macro expand for let-init-else expr)
- #137474 (pretty-print: Print shebang at the top of the output)
- #138872 (rustc_target: RISC-V `Zfinx` is incompatible with `{ILP32,LP64}[FD]` ABIs)
- #139046 (Improve `Lifetime::suggestion`)
- #139206 (std: use the address of `errno` to identify threads in `unique_thread_exit`)
- #139608 (Clarify `async` block behaviour)
- #139847 (Delegate to inner `vec::IntoIter` from `env::ArgsOs`)
- #140159 (Avoid redundant WTF-8 checks in `PathBuf`)
- #140197 (Document breaking out of a named code block)
- #140389 (Remove `avx512dq` and `avx512vl` implication for `avx512fp16`)
- #140430 (Improve test coverage of HIR pretty printing.)
- #140507 (rustc_target: RISC-V: feature addition batch 3)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
To support weird symbol names, including dots in particular.
|
|
|
|
rustc_target: RISC-V: feature addition batch 3
This is the last batch (3 of 3) for RISC-V feature enhancements intended for the version 1.88 cycle.
The author's primary criteria are:
1. The extension is ratified and unprivileged one.
2. The extension is in the RVA23U64 profile (to be a baseline of the application-class RISC-V software ecosystem in the near future), either mandatory or optional.
3. Either:
1. To be discoverable through a `riscv_hwprobe` system call on (currently unreleased) Linux 6.15 (as of rc4) or
2. Helps memory/atomics-related operations more efficient and/or more robust.
This is based on the specifications:
* [The latest ratified ISA Manuals (version 20240411)](https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+Technical+Specifications)
* [RVA23/RVB23 profiles](https://github.com/riscv/riscv-profiles/releases/tag/rva23-rvb23-ratified)
* [RISC-V BF16 extensions](https://github.com/riscv/riscv-bfloat16/releases/tag/v183a3dac863d7c18187a739eb52b0c8f0d16854d)
LLVM Definitions:
* [`Zicbop`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L82-87)
* [`Zicbom`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L75-L80)
* [`Zic64b`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L71-L73)
* [`Ziccamoa`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L97-L99)
* [`Ziccif`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L101-L103)
* [`Zicclsm`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L105-L107)
* [`Ziccrse`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L109-L111)
* [`Zfbfmin`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L320-L325)
* [`Zvfbfmin`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L697-L702)
* [`Zvfbfwma`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L704-L710)
The `Zicbop` extension (mandatory in RVA23U64) adds prefetch hints to prepare for subsequent memory operations (will be executed as no-op if the hardware does not support this extension).
The `Zicbom` extension (mandatory in RVA23U64) adds cache block-management instructions. The author did not include this in the batch 2 (because of limited use cases compared to the `Zicboz` extension) but added because it will be discoverable from Linux (as of version 6.15-rc4). Along with `Zicbop`, Rust now supports all CMO extensions.
The `Zic64b` extension (mandatory in RVA23U64) constraints the cache block to be naturally-aligned and exactly 64 bytes. Along with CMO instructions, it can improve efficiency handling with memory (e.g. efficient memory zeroing using `Zicboz` + `Zic64b`).
The `Zicc*` extensions (mandatory in RVA23U64) add constraints to the main memory properties. They are normally satisfied in the application environment with regular OSes but profiles like RVA23U64 ensures such properties are satisfied (through those *constraint* extensions).
The `Zfbf*` and `Zvfbf*` extensions (optional in RVA23U64) add instructions to handle BF16 (BFloat16) data. Although stabilization of FP-related extensions are relatively far due to ABI-related issues, they are included in this batch because they will be discoverable from Linux (as of version 6.15-rc4).
The author also adds the extension implication: `Za64rs` → `Za128rs` (superset) which the author missed to include in #140139.
|
|
Improve test coverage of HIR pretty printing.
Details in individual commits.
r? `@dtolnay`
try-job: test-various
|
|
Improve `Lifetime::suggestion`
r? ``@lcnr``
|
|
r=workingjubilee
rustc_target: RISC-V `Zfinx` is incompatible with `{ILP32,LP64}[FD]` ABIs
Because RISC-V Calling Conventions note that:
> This means code targeting the `Zfinx` extension always uses the ILP32, ILP32E or LP64 integer calling-convention only ABIs as there is no dedicated hardware floating-point register file.
`{ILP32,LP64}[FD]` ABIs with hardware floating-point calling conventions are incompatible with the `Zfinx` extension.
This commit adds `"zfinx"` to the incompatible feature list to those ABIs and tests whether trying to add `"zdinx"` (that is analogous to `"zfinx"` but in double-precision) on a LP64D ABI configuration results in an error (it also tests extension implication; `Zdinx` requires `Zfinx` extension).
Links: RISC-V psABI specification version 1.0
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/v1.0/riscv-cc.adoc#named-abis>
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/tag/v1.0>
|
|
pretty-print: Print shebang at the top of the output
Shebang should stay at the top of the file, even after pretty-printing.
Closes #134643
|
|
handle paren in macro expand for let-init-else expr
Fixes #131655
This PR modifies the codegen logic of the macro expansion within `let-init-else` expression:
- Before: The expression `let xxx = (mac! {}) else {}` expands to `let xxx = (expanded_ast) else {}`.
- After: The same expression expands to `let xxx = expanded_ast else {}`.
An alternative solution to this issue could involve handling the source code directly when encountering unused parentheses in `let-init-else` expressions. However, this approach might be more cumbersome due to the absence of the necessary data structure.
r? `@petrochenkov`
|
|
|
|
|
|
with revisions
|
|
crashes: more tests
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: x86_64-gnu
try-job: dist-i586-gnu-i586-i686-musl
try-job: test-various
|
|
These randomly break when i change the implementation of format_args!().
|
|
|
|
By taking the existing `expanded-exhaustive.rs` test and running it with
both `Zunpretty=expanded` *and* `Zunpretty=hir`.
Also rename some files, and split the asm parts out so they only run on
x86-64.
|
|
`Path<>` needs to be distinguished from `Path<T>`. This commit does
that, improving some error messages.
|
|
We have coverage for `Foo` and `Foo<T>` but not for `Foo<>`. This commit
adds it. Note that the output has bogus syntax: `impl Foo'a, >`
|
|
folkertdev:naked-function-rustc_std_internal_symbol, r=bjorn3
allow `#[rustc_std_internal_symbol]` in combination with `#[naked]`
The need for this came up in https://github.com/rust-lang/compiler-builtins/pull/897, but in general this seems useful and valid to allow.
Based on a quick scan, I don't think changes to the generated assembly are needed.
cc ``@bjorn3``
|
|
Clean up "const" situation in format_args!().
This cleans up the "const" situation in the format_args!() expansion/lowering.
Rather than marking the Argument::new_display etc. functions as non-const, this marks the Arguments::new_v1 functions as non-const.
Example expansion/lowering of format_args!() in const:
```rust
// Error: cannot call non-const formatting macro in constant functions
const {
fmt::Arguments::new_v1( // Now the error is produced here.
&["Hello, ", "!\n"],
&[
fmt::Argument::new_display(&world) // The error used to be produced here.
],
)
}
```
|
|
Fix handling of LoongArch target features not supported by LLVM 19
Fixes #140455
|
|
rustdoc: Fix doctest heuristic for main fn wrapping
Fixes #140412 which regressed in #140220 that I reviewed. As mentioned in https://github.com/rust-lang/rust/pull/140220#issuecomment-2837061779, at the time I didn't have the time to re-review its latest changes and should've therefore invalided my previous "r=me" and blocked the PR on another review given the fragile nature of the doctest impl. This didn't happen which is my fault.
Contains some other small changes. Diff best reviewed modulo whitespace.
r? ``@GuillaumeGomez``
|
|
|
|
|
|
FCP completed in tracking issue #133962.
|
|
|
|
|
|
|
|
|
|
Rather than marking the Argument::new_display etc. functions as
non-const, this marks the Arguments::new_v1 functions as non-const.
|
|
Because RISC-V Calling Conventions note that:
> This means code targeting the Zfinx extension always uses the ILP32,
> ILP32E or LP64 integer calling-convention only ABIs as there is no
> dedicated hardware floating-point register file.
{ILP32,LP64}[FD] ABIs with hardware floating-point calling conventions
are incompatible with the "Zfinx" extension.
This commit adds "zfinx" to the incompatible feature list to those ABIs
and tests whether trying to add "zdinx" (that is analogous to "zfinx" but
in double-precision) on a LP64D ABI configuration results in an error
(it also tests extension implication; "Zdinx" requires "Zfinx" extension).
Link: RISC-V psABI specification version 1.0
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/tag/v1.0>
|
|
|
|
This commit adds three ratified unprivileged RISC-V extensions related to
BFloat16 (BF16) handling.
Although that they are far from stabilization due to ABI issues, they are
optional extensions of the RVA23U64 profile (application-class processor
profile) and going to be discoverable from the Linux kernel
(as of version 6.15-rc4).
This commit mainly prepares runtime detection of those extensions.
|
