| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #138992 (literal pattern lowering: use the pattern's type instead of the literal's in `const_to_pat`)
- #139211 (interpret: add a version of run_for_validation for &self)
- #139235 (`AstValidator` tweaks)
- #139237 (Add a dep kind for use of the anon node with zero dependencies)
- #139260 (Add dianqk to codegen reviewers)
- #139264 (Fix two incorrect turbofish suggestions)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix two incorrect turbofish suggestions
This fixes #121901
This is my contribution to Rust, and my first contribution to a language parser that I didn't write myself.
I am a bit outside my depth here, so any constructive criticism is appreciated.
|
|
`AstValidator` tweaks
When I read through `AstValidator` there were several things that tripped me up, and made the code harder to understand than I would have liked. This PR addresses them. Best reviewed one commit at a time.
r? ``@davidtwco``
|
|
literal pattern lowering: use the pattern's type instead of the literal's in `const_to_pat`
This has two purposes:
- First, it enables removing the `treat_byte_string_as_slice` fields from `TypeckResults` and `ConstToPat`. A byte string pattern's type will be `&[u8]` when matching on a slice reference, so `const_to_pat` will lower it to a slice ref pattern. I believe this is tested by `tests/ui/match/pattern-deref-miscompile.rs`.
- Second, it will simplify the implementation of byte string literals in deref patterns. If byte string patterns can be given the type `[u8; N]` or `[u8]` during HIR typeck, then nothing needs to be changed in `const_to_pat` in order to lower the patterns `deref!(b"..."): Vec<u8>` and `deref!(b"..."): Box<[u8; 3]>`.
Implementation-wise, this uses `lit_to_const` to make a const with the pattern's type and the literal's valtree; that feels to me like the best way to make sure that the valtree representations of the pattern type and literal are the same. Though it may necessitate later changes to `lit_to_const` to accommodate giving byte string literal patterns non-reference types—would that be reasonable?
This unfortunately doesn't work for the `string_deref_patterns` feature (since that gives string literal patterns the `String` type), so I added a workaround for that. However, once `deref_patterns` supports string literals, it may be able to replace `string_deref_patterns`; the special case for `String` can removed at that point.
r? ``@oli-obk``
|
|
Fixes #121901
|
|
Remove `aux_build` run-make rustc helpers
They provide very little value and makes it more confusing than is
helpful.
Helps with #138066.
r? `@Kobzol`
|
|
Add unstable `--print=crate-root-lint-levels`
This PR implements `--print=crate-root-lint-levels` from MCP 833 https://github.com/rust-lang/compiler-team/issues/833.
Tracking issue: https://github.com/rust-lang/rust/issues/139180
Best reviewed commit by commit.
|
|
Various local trait item iteration cleanups
Adding a trait impl for `Foo` unconditionally affected all queries that are interested in a completely independent trait `Bar`. Perf has no effect on this. We probably don't have a good perf test for this tho.
r? `@compiler-errors`
I am unsure about https://github.com/rust-lang/rust/pull/139018/commits/9d05efb66f7b599eeacb5d2456f844fe4768e865 as it doesn't improve anything wrt incremental, because we still do all the checks for valid `Drop` impls, which subsequently will still invoke many queries and basically keep the depgraph the same.
I want to do
https://github.com/rust-lang/rust/blob/9549077a47099dc826039c051b528d1013740e6f/compiler/rustc_middle/src/ty/trait_def.rs#L141
but would leave that to a follow-up PR, this one changes enough things as it is
|
|
|
|
|
|
Rollup of 14 pull requests
Successful merges:
- #135295 (Check empty SIMD vector in inline asm)
- #138003 (Add the new `amx` target features and the `movrs` target feature)
- #138823 (rustc_target: RISC-V: add base `I`-related important extensions)
- #138913 (Remove even more instances of `@ts-expect-error` from search.js)
- #138941 (Do not mix normalized and unnormalized caller bounds when constructing param-env for `receiver_is_dispatchable`)
- #139060 (replace commit placeholder in vendor status with actual commit)
- #139102 (coverage: Avoid splitting spans during span extraction/refinement)
- #139191 (small opaque type/borrowck cleanup)
- #139200 (Skip suggest impl or dyn when poly trait is not a real trait)
- #139208 (fix dead link netbsd.md)
- #139210 (chore: remove redundant backtick)
- #139212 (Update mdbook to 0.4.48)
- #139214 (Tell rustfmt to use the 2024 edition in ./x.py fmt)
- #139225 (move autodiff from EnzymeAD/Enzyme to our rust-lang/Enzyme soft-fork)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Tell rustfmt to use the 2024 edition in ./x.py fmt
Most crates in this repo have been moved to the 2024 edition already. This also allows removing a rustfmt exclusion for a cg_clif test.
|
|
Skip suggest impl or dyn when poly trait is not a real trait
Fixes #139174
When `poly_trait_ref` is not a real trait, we should stop suggesting `impl` and `dyn` to avoid false positives. 3 cases were added to the ui test.
https://github.com/rust-lang/rust/blob/0b45675cfcec57f30a3794e1a1e18423aa9cf200/compiler/rustc_hir_analysis/src/hir_ty_lowering/lint.rs#L88-L93
In the first commit, I submitted the test and passed it. In the second commit, I modified the code and we can see the changes in the test.
r? compiler
|
|
coverage: Avoid splitting spans during span extraction/refinement
This PR removes or simplifies some of the steps involved in extracting coverage-relevant spans from MIR, and preparing them for use in coverage instrumentation metadata.
A common theme is that we now try harder to avoid modifying or combining spans in non-trivial ways, because those modifications present the most risk for weird behaviour or ICEs.
The main changes are:
- When extracting spans from MIR call terminators, try to restrict them to just the function name.
- Instead of splitting spans around “holes”, just discard any span that overlaps with a hole.
- Instead of splitting macro-invocation spans into two parts, truncate them to just the macro name and subsequent `!`.
---
This results in a lot of tiny changes to the spans that end up in coverage metadata, and a few changes to coverage reports. Judging by test snapshots, these changes appear to be quite minor in practice.
|
|
r=BoxyUwU
Do not mix normalized and unnormalized caller bounds when constructing param-env for `receiver_is_dispatchable`
See comments in code and in test I added.
r? `@BoxyUwU` since you reviewed the last PR, or reassign
Fixes #138937
|
|
rustc_target: RISC-V: add base `I`-related important extensions
Of ratified RISC-V features defined, this commit adds extensions satisfying following criteria:
* Formerly a part of the `I` extension and splitted thereafter (now ratified as `I` + `Zifencei` + `Zicsr` + `Zicntr` + `Zihpm`) or
* Dicoverable from newer versions of the Linux kernel and implemented as a part of `std_detect`'s feature (`Zihintpause`) and
* Available on LLVM 18.
This is based on [the latest ratified ISA Manuals (version 20240411)](https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+Technical+Specifications).
LLVM Definitions:
* [`Zifencei`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L133-L137)
* [`Zicsr`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L116-L120)
* [`Zicntr`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L122-L124)
* [`Zihpm`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L153-L155)
* [`Zihintpause`](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L139-L144)
Additional (1):
One of those, `Zicsr`, is a dependency of many other ISA extensions and this commit adds correct dependencies to `Zicsr`.
Additional (2):
In RISC-V, `G` is an abbreviation of following extensions:
* `I`
* `M`
* `A`
* `F`
* `D`
* `Zicsr` (although implied by `F`)
* `Zifencei`
and all RISC-V targets with the `G` abbreviation and targets for Android / VxWorks are updated accordingly.
Note:
Android will require RVA22 (likely RVA22U64) and some more extensions, which is a superset of RV64GC. For VxWorks, all BSPs currently distributed by Wind River are for boards with RV64GC (this commit also updates `riscv32-wrs-vxworks` though).
--------
This is the version 4.
`Ztso` in the original proposal is removed on the PR version 2 due to the minimum LLVM version (non-experimental `Ztso` requires LLVM 19 while minimum LLVM version of Rust is 18). This is not back in PR version 3 and 4 after noticing adding `Ztso` is possible by checking host LLVM version because PR version 3 introduces compiler target changes (and adding more extensions would complicate the problems; sorry `Zihintpause`).
Version 4:
* Fixed some commit messages,
* Added Android / VxWorks targets to imply `G` and
* Added an implication from `Zve32x` to `Zicsr` (which makes all vector extension subsets to imply `Zicsr`)
since #138742 is now merged.
Related:
* #44839
(`riscv_target_feature`)
* #114544
(This PR can be a prerequisite of resolving a part of that tracking issue)
* #138742
(Touches the same place and vector extensions depend on `Zicsr`)
NOT Related but linked:
* #132618
(This PR won't be blocked by this issue since none of those extensions do not change the ABI)
`@rustbot` r? `@Amanieu`
`@rustbot` label +T-compiler +O-riscv +A-target-feature
|
|
Add the new `amx` target features and the `movrs` target feature
Adds 5 new `amx` target features included in LLVM20. These are guarded under `x86_amx_intrinsics` (#126622)
- `amx-avx512`
- `amx-fp8`
- `amx-movrs`
- `amx-tf32`
- `amx-transpose`
Adds the `movrs` target feature (from #137976).
`@rustbot` label O-x86_64 O-x86_32 T-compiler A-target-feature
r? `@Amanieu`
|
|
Check empty SIMD vector in inline asm
fixes [#134334](https://github.com/rust-lang/rust/issues/134334)
|
|
Of ratified RISC-V features defined, this commit adds extensions
satisfying following criteria:
* Formerly a part of the "I" extension and splitted thereafter
(now ratified as "I" + "Zifencei" + "Zicsr" + "Zicntr" + "Zihpm") or
* Dicoverable from newer versions of the Linux kernel and implemented
as a part of std_detect's feature ("Zihintpause").
This is based on the latest ratified ISA Manuals (version 20240411).
Additional (1):
One of those, "Zicsr", is a dependency of many other ISA extensions and
this commit adds correct dependencies to "Zicsr".
Additional (2):
In RISC-V, "G" is an abbreviation of following extensions:
* "I"
* "M"
* "A"
* "F"
* "D"
* "Zicsr" (although implied by "F")
* "Zifencei"
and all RISC-V targets with the "G" abbreviation and targets for Android /
VxWorks are updated accordingly.
Note:
Android will require RVA22 (likely RVA22U64) and some more extensions,
which is a superset of RV64GC. For VxWorks, all BSPs currently distributed
by Wind River are for boards with RV64GC (this commit also updates
riscv32-wrs-vxworks though).
|
|
Remove `NtExpr` and `NtLiteral`
The next part of #124141.
r? `@petrochenkov`
|
|
Currently it uses `walk_item` on some item kinds. For other item kinds
it visits the fields individually. For the latter group, this commit
adds `visit_attrs_vis` and `visit_attrs_vis_ident` which bundle up
visits to the fields that don't need special handling. This makes it
clearer that they haven't been forgotten about.
Also, it's better to do the attribute visits at the start because
attributes precede the items in the source code. Because of this, a
couple of tests have their output improved: errors appear in an order
that matches the source code order.
|
|
This makes the expression re-parsing more like how it's originally done
in `parse_nonterminal`.
|
|
|
|
Notes about tests:
- tests/ui/rfcs/rfc-2294-if-let-guard/feature-gate.rs: some messages are
now duplicated due to repeated parsing.
- tests/ui/rfcs/rfc-2497-if-let-chains/disallowed-positions.rs: ditto.
- `tests/ui/proc-macro/macro-rules-derive-cfg.rs`: the diff looks large
but the only difference is the insertion of a single
invisible-delimited group around a metavar.
- `tests/ui/attributes/nonterminal-expansion.rs`: a slight span
degradation, somehow related to the recent massive attr parsing
rewrite (#135726). I couldn't work out exactly what is going wrong,
but I don't think it's worth holding things up for a single slightly
suboptimal error message.
|
|
Feed HIR for by-move coroutine body def, since the inliner tries to read its attrs
See the comments in the test.
I'm surprised that nobody found this[^1] (edit: nvm haha), but you have to go out of your way to construct the by-move body and then inline it w/ a poll call, so I guess the inliner just never really gets into this situation before.
Fixes #134335
r? oli-obk
[^1]: Well, ````@eholk```` found this when working on the `iter! {}` macro, since it more dramatically affects those.
|
|
PassWrapper: adapt for llvm/llvm-project@94122d58fc77079a291a3d008914…
…006cb509d9db
We also have to remove the LLVM argument in cast-target-abi.rs for LLVM
21. I'm not really sure what the best approach here is since that test already uses revisions. We could also fork the test into a copy for LLVM 19-20 and another for LLVM 21, but what I did for now was drop the lint-abort-on-error flag to LLVM figuring that some coverage was better than none, but I'm happy to change this if that was a bad direction.
r? dianqk
````@rustbot```` label llvm-main
|
|
reez12g:add-tests-for-slice-bounds-check-optimization, r=fee1-dead
Add tests for slice bounds check optimization
Closes https://github.com/rust-lang/rust/issues/134466
|
|
increment depth of nested obligations
properly fixes the root cause of #109268. While we didn't get hangs here before, I ended up encountering its root cause again with #138785.
r? types
|
|
Note potential but private items in show_candidates
Closes #138626 .
We should add potential private items to give ample hints.
And for the other seemingly false positive ` pub use crate::one::Foo;` should be kept because we don't know if the user wants to import other module's items or not, and therefore should be given the full option to do so.
r? compiler
|
|
rustdoc-json: Add test for #[automatically_derived] attribute
~~Will fail CI due to https://github.com/freestrings/jsonpath/issues/91, but I wrote the test and don't want to forget it.~~
~~We should look into fixing the freestrings impl, or moving to a different one, so we can test things like this. [Zulip Disussion](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/jsonpath-plus.20integration)~~
FIXED!!! By #138763
r? ````@ghost````
````@rustbot```` blocked
|
|
|
|
|
|
remove `feature(inline_const_pat)`
Summarizing https://rust-lang.zulipchat.com/#narrow/channel/144729-t-types/topic/remove.20feature.28inline_const_pat.29.20and.20shared.20borrowck.
With https://github.com/rust-lang/types-team/issues/129 we will start to borrowck items together with their typeck parent. This is necessary to correctly support opaque types, blocking the new solver and TAIT/ATPIT stabilization with the old one. This means that we cannot really support `inline_const_pat` as they are implemented right now:
- we want to typeck inline consts together with their parent body to allow inference to flow both ways and to allow the const to refer to local regions of its parent.This means we also need to borrowck the inline const together with its parent as that's necessary to properly support opaque types
- we want the inline const pattern to participate in exhaustiveness checking
- to participate in exhaustiveness checking we need to evaluate it, which requires borrowck, which now relies on borrowck of the typeck root, which ends up checking exhaustiveness again. **This is a query cycle**.
There are 4 possible ways to handle this:
- stop typechecking inline const patterns together with their parent
- causes inline const patterns to be different than inline const exprs
- prevents bidirectional inference, we need to either fail to compile `if let const { 1 } = 1u32` or `if let const { 1u32 } = 1`
- region inference for inline consts will be harder, it feels non-trivial to support inline consts referencing local regions from the parent fn
- inline consts no longer participate in exhaustiveness checking. Treat them like `pat if pat == const { .. }` instead. We then only evaluate them after borrowck
- difference between `const { 1 }` and `const FOO: usize = 1; match x { FOO => () }`. This is confusing
- do they carry their weight if they are now just equivalent to using an if-guard
- delay exhaustiveness checking until after borrowck
- should be possible in theory, but is a quite involved change and may have some unexpected challenges
- remove this feature for now
I believe we should either delay exhaustiveness checking or remove the feature entirely. As moving exhaustiveness checking to after borrow checking is quite complex I think the right course of action is to fully remove the feature for now and to add it again once/if we've got that implementation figured out.
`const { .. }`-expressions remain stable. These seem to have been the main motivation for https://github.com/rust-lang/rfcs/issues/2920.
r? types
cc `@rust-lang/types` `@rust-lang/lang` #76001
|
|
Introduce `-Zembed-metadata` to allow omitting full metadata from rlibs and dylibs
This is a continuation of https://github.com/rust-lang/rust/pull/120855 (I was mentored by `@bjorn3` to move it forward). Most of the original code was written by bjorn3, I tried to clean it up a bit and add some documentation and tests.
This PR introduces a new unstable compiler flag called `-Zembed-metadata=[no|yes]`, with the default being `yes` (see https://github.com/rust-lang/rust/issues/57076 for context). When set to `no`, rustc will only store a small metadata stub inside rlibs/dylibs instead of the full metadata, to keep their size smaller. It should be used in combination with `--emit=metadata`, so that the users of such a compiled library can still read the metadata from the corresponding `.rmeta` file. [This comment](https://github.com/rust-lang/rust/pull/120855#issuecomment-1937018169) shows an example of binary/artifact size wins that can be achieved using this approach.
Contrary to https://github.com/rust-lang/rust/pull/120855, this PR only introduces the new flag, along with a couple of run-make tests and documentation, but does not yet use it in bootstrap to actually compile rustc. I plan to do that as a follow-up step (along with integration in Cargo, which should ideally just always pass this flag to reduce the size of target directories).
Fixes https://github.com/rust-lang/rust/issues/23366
Closes https://github.com/rust-lang/rust/issues/29511
Fixes https://github.com/rust-lang/rust/issues/57076
Another attempt of https://github.com/rust-lang/rust/pull/93945 and https://github.com/rust-lang/rust/pull/120855.
r? `@petrochenkov`
|
|
|
|
Move `ast::Item::ident` into `ast::ItemKind`
The follow-up to #138384, which did the same thing for `hir::ItemKind`.
r? `@fmease`
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
|
|
`ast::Item` has an `ident` field.
- It's always non-empty for these item kinds: `ExternCrate`, `Static`,
`Const`, `Fn`, `Mod`, `TyAlias`, `Enum`, `Struct`, `Union`,
`Trait`, `TraitAlias`, `MacroDef`, `Delegation`.
- It's always empty for these item kinds: `Use`, `ForeignMod`,
`GlobalAsm`, `Impl`, `MacCall`, `DelegationMac`.
There is a similar story for `AssocItemKind` and `ForeignItemKind`.
Some sites that handle items check for an empty ident, some don't. This
is a very C-like way of doing things, but this is Rust, we have sum
types, we can do this properly and never forget to check for the
exceptional case and never YOLO possibly empty identifiers (or possibly
dummy spans) around and hope that things will work out.
The commit is large but it's mostly obvious plumbing work. Some notable
things.
- `ast::Item` got 8 bytes bigger. This could be avoided by boxing the
fields within some of the `ast::ItemKind` variants (specifically:
`Struct`, `Union`, `Enum`). I might do that in a follow-up; this
commit is big enough already.
- For the visitors: `FnKind` no longer needs an `ident` field because
the `Fn` within how has one.
- In the parser, the `ItemInfo` typedef is no longer needed. It was used
in various places to return an `Ident` alongside an `ItemKind`, but
now the `Ident` (if present) is within the `ItemKind`.
- In a few places I renamed identifier variables called `name` (or
`foo_name`) as `ident` (or `foo_ident`), to better match the type, and
because `name` is normally used for `Symbol`s. It's confusing to see
something like `foo_name.name`.
|
|
`expand_test_case` looks for any item with a `#[test_case]` attribute
and adds a `test_path_symbol` attribute to it while also fiddling with
the item's ident's span.
This is pretty weird, because `#[test_case]` is only valid on
`fn`/`const`/`static` items, as far as I can tell. But you don't
currently get an error or warning if you use it on other kinds of items.
This commit changes things so that a `#[test_case]` item is modified
only if it is `fn`/`const`/`static`. This is relevant for moving idents
from `Item` to `ItemKind`, because some item kinds don't have an ident,
e.g. `impl` blocks.
The commit also does the following.
- Renames a local variable `test_id` as `test_ident`.
- Changes a `const` to `static` in
`tests/ui/custom_test_frameworks/full.rs` to give the `static` case
some test coverage.
- Adds a `struct` and `impl` to the same test to give some test coverage
to the non-affected item kinds. These have a `FIXME` comment
identifying the weirdness here. Hopefully this will be useful
breadcrumbs for somebody else in the future.
|
|
|
|
|
|
This is a way to shrink call spans that doesn't involve mixing different spans,
and avoids overlap with argument spans.
This patch also removes some low-value comments that were causing rustfmt to
ignore the match arms.
|
|
This test is intended to demonstrate that a particular macro-argument span
doesn't get lost during span-refinement, but it turns out that span-extraction
currently doesn't yield any MIR spans for this position.
This patch therefore tweaks the test to add a function call in that position,
so that it still remains relevant to span refinement.
|
|
|
|
attrs
|
|
Remove fragile equal-pointers-unequal/*/print3.rs tests.
These tests were added in #127003
The print3.rs tests stop working when I change implementation details of format_args!(). (For example, in https://github.com/rust-lang/rust/pull/139175 and https://github.com/rust-lang/rust/pull/139135). These tests shouldn't rely on such implementation details. It gets in the way for format_args!() improvements.
If they test anything that aren't already covered by the other tests in this directory, 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.
|
|
rustc_resolve: Test the order that preludes are resolved
This test is exhaustive. See attached truth table:
Companion PR to https://github.com/rust-lang/reference/pull/1765.
|
