| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
`for_each_assignment_mut` can skip assignment statements with side effects,
which can result in some assignment statements retrieving outdated value.
For example, it may skip a dereference assignment statement.
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
`AstValidator` has several `with_*` methods, each one setting a field
that adjust how checking takes place for items within certain other
items. E.g. `with_in_trait_impl` is used to adjust the checking done on
items inside an `impl` item. Weirdly, the scopes used for most of the
`with_*` calls are very broad, and include things that aren't "inside"
the item, such as visibility, unsafety, and constness.
This commit minimizes the scope of these `with_*` calls so they only
apply to the things inside the item.
|
|
|
|
|
|
|
|
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
|
|
A bunch of span-related names in `AstValidator` don't end in `span`,
which goes against the usual naming conventions and makes the code
surprisingly hard to read. E.g. a name like `body` doesn't sound like
it's a span.
This commit adds `_span` suffixes.
|
|
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
|
|
small opaque type/borrowck cleanup
pulled out of #138785
|
|
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`
|
|
This eliminates all methods on `Map`. Actually removing `Map` will occur
in a follow-up PR.
|
|
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.
|
|
|
|
|
|
Currently some code paths return early, while others fall through to the
`visit::walk_item` call, which is easy to overlook (I did, at first),
even with the explanatory comments.
This commit removes the early returns and moves the `visit::walk_item`
calls up where necessary. This makes the function easier to read and
slightly shorter.
|
|
This makes the expression re-parsing more like how it's originally done
in `parse_nonterminal`.
|
|
|
|
In favour of the similar method on `Parser`, which works on things
other than identifiers and lifetimes.
|
|
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.
|
|
|
|
Improve docs of ValTreeKind
|
|
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
|
|
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
|
|
|
|
|
|
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`
|
|
|
|
|
|
|
