| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #138712 (resolve: Support imports of associated types and glob imports from traits)
- #140395 (organize and extend forbidden target feature tests)
- #140576 (Remove fragile equal-pointers-unequal tests.)
- #140582 (Update sysinfo to `0.35.0` in bootstrap and `tools/opt-dist`)
- #140595 (doc(std): fix typo lchown -> lchmod)
- #140597 (zkvm: remove schmerik as target maintainer)
- #140604 (yet another small borrowck cleanup )
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
yet another small borrowck cleanup
The last borrowck changes from #139587 which can be reviewed entirely separately.
r? `@compiler-errors`
|
|
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.
|
|
Use a closure instead of three chained iterators
Fixes the perf regression from #123948
That PR had chained a third option to the iterator which apparently didn't optimize well
|
|
Improve hir pretty printing
It's currently pretty bad, so a few small improvements can make a big difference.
r? `@dtolnay`
|
|
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
|
|
PassWrapper: adapt for llvm/llvm-project@f137c3d592e96330e450a8fd63ef…
…7e8877fc1908
In LLVM 21 PR https://github.com/llvm/llvm-project/pull/130940 `TargetRegistry::createTargetMachine` was changed to take a `const Triple&` and has deprecated the old `StringRef` method.
``@rustbot`` label llvm-main
|
|
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)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r=wesleywiser
mono collector: Reduce # of locking while walking the graph
While profiling Zed's dev build I've noticed that while most of the time `upstream_monomorphizations` takes a lot of time in monomorpization_collector, in some cases (e.g. build of `editor` itself) the rest of monomorphization_collector_graph_walk dominates it. Most of the time is spent in collect_items_rec.
This PR aims to reduce the number of locks taking place; instead of locking output MonoItems once per children of current node, we do so once per *current node*. We also get to reuse locks for mentioned and used items. While this commit does not reduce Wall time of Zed's build, it does shave off CPU time (measured with `cargo build -j1`) from 48s to 47s. I've also tested it with parallel frontend against Zed and ripgrep and found no regressions.
|
|
All the box open/close issues have been fixed.
|
|
One of the boxes isn't closed, and this causes everything after it to be
over-indented.
|
|
As far as I can tell, this code is not actually reachable.
|
|
They don't appear to do anything -- no test output is affected -- and no
other pretty-printing code looks like this.
|
|
Rollup of 9 pull requests
Successful merges:
- #140485 (Optimize the codegen for `Span::from_expansion`)
- #140509 (transmutability: merge contiguous runs with a common destination)
- #140519 (Use select in projection lookup in `report_projection_error`)
- #140521 (interpret: better error message for out-of-bounds pointer arithmetic and accesses)
- #140536 (Rename `*Guard::try_map` to `filter_map`.)
- #140550 (Stabilize `select_unpredictable`)
- #140563 (extend the list of registered dylibs on `test::prepare_cargo_test`)
- #140572 (Add useful comments on `ExprKind::If` variants.)
- #140574 (Add regression test for 133065)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Add useful comments on `ExprKind::If` variants.
Things that aren't obvious and took me a while to work out.
r? `@BoxyUwU`
|
|
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
|
|
transmutability: merge contiguous runs with a common destination
Based on #140380.
r? `@jswrenn` `@joshlf`
|
|
Optimize the codegen for `Span::from_expansion`
See https://godbolt.org/z/bq65Y6bc4 for the difference. the new version is less than half the number of instructions.
Also tried fully writing the function by hand:
```rust
sp.ctxt_or_parent_or_marker != 0
&& (
sp.len_with_tag_or_marker == BASE_LEN_INTERNED_MARKER
|| sp.len_with_tag_or_marker & PARENT_TAG == 0
)
```
But that was no better than this PR's current use of `match_span_kind`.
|
|
perf: delay checking of `#[rustc_no_implicit_autorefs]` in autoref lint
Try to address the regression seen in https://github.com/rust-lang/rust/pull/123239#issuecomment-2835418470 by delaying the checking of `#[rustc_no_implicit_autorefs]` on method call.
|
|
|
|
|
|
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
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.
|
|
Remove `avx512dq` and `avx512vl` implication for `avx512fp16`
According to Intel, `avx512fp16` requires only `avx512bw`, but LLVM also enables `avx512vl` and `avx512dq` when `avx512fp16` is active. This is relic code, and will be fixed in LLVM soon. We should remove this from Rust too asap, especially before the stabilization of AVX512
Related:
- llvm/llvm-project#136209
- #138940
- rust-lang/stdarch#1781
- #111137
``@rustbot`` label O-x86_64 O-x86_32 A-SIMD A-target-feature T-compiler -T-libs
r? ``@Amanieu``
**Update: the LLVM fix has been merged**
cc ``@rust-lang/wg-llvm`` will it be possible to update the rustc llvm version to something after llvm/llvm-project#137450
|
|
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`
|
|
|
|
|
|
|
