| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=compiler-errors,petrochenkov
`f16` and `f128` step 3: compiler support & feature gate
Continuation of https://github.com/rust-lang/rust/pull/121841, another portion of https://github.com/rust-lang/rust/pull/114607
This PR exposes the new types to the world and adds a feature gate. Marking this as a draft because I need some feedback on where I did the feature gate check. It also does not yet catch type via suffixed literals (so the feature gate test will fail, probably some others too because I haven't belssed).
If there is a better place to check all types after resolution, I can do that. If not, I figure maybe I can add a second gate location in AST when it checks numeric suffixes.
Unfortunately I still don't think there is much testing to be done for correctness (codegen tests or parsed value checks) until we have basic library support. I think that will be the next step.
Tracking issue: https://github.com/rust-lang/rust/issues/116909
r? `@compiler-errors`
cc `@Nilstrieb`
`@rustbot` label +F-f16_and_f128
|
|
hir: Remove `opt_local_def_id_to_hir_id` and `opt_hir_node_by_def_id`
Also replace a few `hir_node()` calls with `hir_node_by_def_id()`.
Follow up to https://github.com/rust-lang/rust/pull/120943.
|
|
Docs for `thir::ExprKind::Use` and `thir::ExprKind::Let`
These docs are based on my own recent investigations; hopefully they're reasonably accurate.
`Use` was particularly puzzling to me at first, since the name is not very suggestive, and the old docs were quite cryptic.
|
|
|
|
Fill in HIR hash for associated opaque types
Fixes https://github.com/rust-lang/rust/issues/122508
|
|
Rollup of 10 pull requests
Successful merges:
- #117118 ([AIX] Remove AixLinker's debuginfo() implementation)
- #121650 (change std::process to drop supplementary groups based on CAP_SETGID)
- #121764 (Make incremental sessions identity no longer depend on the crate names provided by source code)
- #122212 (Copy byval argument to alloca if alignment is insufficient)
- #122322 (coverage: Initial support for branch coverage instrumentation)
- #122373 (Fix the conflict problem between the diagnostics fixes of lint `unnecessary_qualification` and `unused_imports`)
- #122479 (Implement `Duration::as_millis_{f64,f32}`)
- #122487 (Rename `StmtKind::Local` variant into `StmtKind::Let`)
- #122498 (Update version of cc crate)
- #122503 (Make `SubdiagMessageOp` well-formed)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Also replace a few `hir_node()` calls with `hir_node_by_def_id()`
|
|
Rename `StmtKind::Local` variant into `StmtKind::Let`
It comes from this [discussion](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Improve.20naming.20of.20.60ExprKind.3A.3ALet.60.3F).
Starting point was:
> I often end up looking at [ExprKind::Let](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir/enum.ExprKind.html#variant.Let) instead of Local because of the name. I think renaming it (both the `ExprKind` variant and the Let struct) to `LetPattern` or LetPat could improve the situation as I'm not sure I'm not the only one encountering this issue.
And then it evolved into:
> It's already `Expr::Let` instead of `StmtKind::Local`. Counterproposal: rename `StmtKind::Local` to `StmtKind::Let`.
The goal here is to clear this confusion.
r? `@oli-obk`
|
|
coverage: Initial support for branch coverage instrumentation
(This is a review-ready version of the changes that were drafted in #118305.)
This PR adds support for branch coverage instrumentation, gated behind the unstable flag value `-Zcoverage-options=branch`. (Coverage instrumentation must also be enabled with `-Cinstrument-coverage`.)
During THIR-to-MIR lowering (MIR building), if branch coverage is enabled, we collect additional information about branch conditions and their corresponding then/else blocks. We inject special marker statements into those blocks, so that the `InstrumentCoverage` MIR pass can reliably identify them even after the initially-built MIR has been simplified and renumbered.
The rest of the changes are mostly just plumbing needed to gather up the information that was collected during MIR building, and include it in the coverage metadata that we embed in the final binary.
Note that `llvm-cov show` doesn't print branch coverage information in its source views by default; that needs to be explicitly enabled with `--show-branches=count` or similar.
---
The current implementation doesn't have any support for instrumenting `if let` or let-chains. I think it's still useful without that, and adding it would be non-trivial, so I'm happy to leave that for future work.
|
|
more eagerly instantiate binders
The old solver sometimes incorrectly used `sub`, change it to explicitly instantiate binders and use `eq` instead. While doing so I also moved the instantiation before the normalize calls. This caused some observable changes, will explain these inline. This PR therefore requires a crater run and an FCP.
r? types
|
|
Rollup of 10 pull requests
Successful merges:
- #119029 (Avoid closing invalid handles)
- #122238 (Document some builtin impls in the next solver)
- #122247 (rustdoc-search: depth limit `T<U>` -> `U` unboxing)
- #122287 (add test ensuring simd codegen checks don't run when a static assertion failed)
- #122368 (chore: remove repetitive words)
- #122397 (Various cleanups around the const eval query providers)
- #122406 (Fix WF for `AsyncFnKindHelper` in new trait solver)
- #122477 (Change some attribute to only_local)
- #122482 (Ungate the `UNKNOWN_OR_MALFORMED_DIAGNOSTIC_ATTRIBUTES` lint)
- #122490 (Update build instructions for OpenHarmony)
Failed merges:
- #122471 (preserve span when evaluating mir::ConstOperand)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Fix WF for `AsyncFnKindHelper` in new trait solver
`to_opt_closure_kind` ICEs when it sees placeholders... so don't do that
no test b/c I'm too lazy to write a no-core test for this, but I could be convinced otherwise
r? lcnr
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This will allow MIR building to check whether a function is eligible for
coverage instrumentation, and avoid collecting branch coverage info if it is
not.
|
|
|
|
|
|
|
|
|
|
Will be used in the next commit
|
|
|
|
`DefiningAnchor::Bind` with an empty list
|
|
constrained, instead of the current infcx root item.
This makes `Bind` almost always be empty, so we can start forwarding it to queries, allowing us to remove `Bubble` entirely
|
|
Diagnostic renaming 3
A sequel to https://github.com/rust-lang/rust/pull/121780.
r? `@davidtwco`
|
|
To match `derive(LintDiagnostic)`.
|
|
To match `derive(Diagnostic)`.
Also rename `into_diagnostic` as `into_diag`.
|
|
Also rename `into_diagnostic_arg` as `into_diag_arg`, and
`NotIntoDiagnosticArg` as `NotInotDiagArg`.
|
|
consistent way
|
|
Dep node encoding cleanups
This does some cleanups around dep node encoding.
Performance change with `-Zthreads=2`:
<table><tr><td rowspan="2">Benchmark</td><td colspan="1"><b>Before</b></th><td colspan="2"><b>After</b></th><td colspan="1"><b>Before</b></th><td colspan="2"><b>After</b></th></tr><tr><td align="right">Time</td><td align="right">Time</td><td align="right">%</th><td align="right">Memory</td><td align="right">Memory</td><td align="right">%</th></tr><tr><td>🟣 <b>clap</b>:check:unchanged</td><td align="right">0.4337s</td><td align="right">0.4306s</td><td align="right"> -0.72%</td><td align="right">88.90 MiB</td><td align="right">89.04 MiB</td><td align="right"> 0.15%</td></tr><tr><td>🟣 <b>hyper</b>:check:unchanged</td><td align="right">0.1541s</td><td align="right">0.1528s</td><td align="right"> -0.86%</td><td align="right">51.99 MiB</td><td align="right">52.03 MiB</td><td align="right"> 0.07%</td></tr><tr><td>🟣 <b>regex</b>:check:unchanged</td><td align="right">0.3286s</td><td align="right">0.3248s</td><td align="right">💚 -1.15%</td><td align="right">71.89 MiB</td><td align="right">71.74 MiB</td><td align="right"> -0.21%</td></tr><tr><td>🟣 <b>syn</b>:check:unchanged</td><td align="right">0.6118s</td><td align="right">0.6057s</td><td align="right">💚 -1.01%</td><td align="right">106.59 MiB</td><td align="right">106.66 MiB</td><td align="right"> 0.06%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check:unchanged</td><td align="right">1.4570s</td><td align="right">1.4463s</td><td align="right"> -0.74%</td><td align="right">197.29 MiB</td><td align="right">197.33 MiB</td><td align="right"> 0.02%</td></tr><tr><td>Total</td><td align="right">2.9852s</td><td align="right">2.9601s</td><td align="right"> -0.84%</td><td align="right">516.66 MiB</td><td align="right">516.80 MiB</td><td align="right"> 0.03%</td></tr><tr><td>Summary</td><td align="right">1.0000s</td><td align="right">0.9911s</td><td align="right"> -0.89%</td><td align="right">1 byte</td><td align="right">1.00 bytes</td><td align="right"> 0.02%</td></tr></table>
r? `@cjgillot`
|
|
Distinguish between library and lang UB in assert_unsafe_precondition
As described in https://github.com/rust-lang/rust/pull/121583#issuecomment-1963168186, `assert_unsafe_precondition` now explicitly distinguishes between language UB (conditions we explicitly optimize on) and library UB (things we document you shouldn't do, and maybe some library internals assume you don't do).
`debug_assert_nounwind` was originally added to avoid the "only at runtime" aspect of `assert_unsafe_precondition`. Since then the difference between the macros has gotten muddied. This totally revamps the situation.
Now _all_ preconditions shall be checked with `assert_unsafe_precondition`. If you have a precondition that's only checkable at runtime, do a `const_eval_select` hack, as done in this PR.
r? RalfJung
|
|
Remove `Ord` from `ClosureKind`
Using `Ord` to accomplish a meaning of subset relationship can be hard to read. The existing uses for that are easily replaced with a `match`, and in my opinion, more readable without needing to resorting to comments to explain the intention.
cc `@compiler-errors`
|
|
Using `Ord` to accomplish a meaning of subset relationship
can be hard to read. The existing uses for that are easily
replaced with a `match`, and in my opinion, more readable
without needing to resorting to comments to explain the
intention.
|
|
|
|
Avoid invoking the `intrinsic` query for DefKinds other than `Fn` or `AssocFn`
fixes the perf regression from https://github.com/rust-lang/rust/pull/120675 by only invoking (and thus inserting into the dep graph) the `intrinsic` query if the `DefKind` matches items that can actually be intrinsics
|
|
|
|
inspect formatter: add braces
This makes it easier to hide subtrees when looking through proof trees. Looking at the proof tree for `usize: Clone`:
nightly:
```
ROOT GOAL: Goal { predicate: Binder { value: TraitPredicate(<usize as std::clone::Clone>, polarity:Positive), bound_vars: [] }, param_env: ParamEnv { caller_bounds: [], reveal: UserFacing } }
GOAL: Canonical { value: QueryInput { goal: Goal { predicate: Binder { value: TraitPredicate(<usize as std::clone::Clone>, polarity:Positive), bound_vars: [] }, param_env: ParamEnv { caller_bounds: [], reveal: UserFacing } }, anchor: Bind(DefId(0:5 ~ main[8e4b]::main)), predefined_opaques_in_body: PredefinedOpaques(PredefinedOpaquesData { opaque_types: [] }) }, max_universe: U0, variables: [] }
REVISION 0
INSTANTIATED: QueryInput { goal: Goal { predicate: Binder { value: TraitPredicate(<usize as std::clone::Clone>, polarity:Positive), bound_vars: [] }, param_env: ParamEnv { caller_bounds: [], reveal: UserFacing } }, anchor: Bind(DefId(0:5 ~ main[8e4b]::main)), predefined_opaques_in_body: PredefinedOpaques(PredefinedOpaquesData { opaque_types: [] }) }
ROOT RESULT: Ok(Canonical { value: Response { certainty: Yes, var_values: CanonicalVarValues { var_values: [] }, external_constraints: ExternalConstraints(ExternalConstraintsData { region_constraints: QueryRegionConstraints { outlives: [], member_constraints: [] }, opaque_types: [] }) }, max_universe: U0, variables: [] })
CANDIDATE Impl(DefId(2:30665 ~ core[a9f5]::clone::impls::{impl#5})): Ok(Canonical { value: Response { certainty: Yes, var_values: CanonicalVarValues { var_values: [] }, external_constraints: ExternalConstraints(ExternalConstraintsData { region_constraints: QueryRegionConstraints { outlives: [], member_constraints: [] }, opaque_types: [] }) }, max_universe: U0, variables: [] })
TRY_EVALUATE_ADDED_GOALS: Ok(Yes)
ITERATION 0
CANDIDATE constituent tys: Err(NoSolution)
NORMALIZING SELF TY FOR ASSEMBLY:
NORMALIZING SELF TY FOR ASSEMBLY:
RESULT: Ok(Canonical { value: Response { certainty: Yes, var_values: CanonicalVarValues { var_values: [] }, external_constraints: ExternalConstraints(ExternalConstraintsData { region_constraints: QueryRegionConstraints { outlives: [], member_constraints: [] }, opaque_types: [] }) }, max_universe: U0, variables: [] })
```
with this PR:
```
ROOT GOAL: Goal { predicate: Binder { value: TraitPredicate(<usize as std::clone::Clone>, polarity:Positive), bound_vars: [] }, param_env: ParamEnv { caller_bounds: [], reveal: UserFacing } } {
GOAL: Canonical { value: QueryInput { goal: Goal { predicate: Binder { value: TraitPredicate(<usize as std::clone::Clone>, polarity:Positive), bound_vars: [] }, param_env: ParamEnv { caller_bounds: [], reveal: UserFacing } }, anchor: Bind(DefId(0:5 ~ main[4f74]::main)), predefined_opaques_in_body: PredefinedOpaques(PredefinedOpaquesData { opaque_types: [] }) }, max_universe: U0, variables: [] }
REVISION 0: {
INSTANTIATED: QueryInput { goal: Goal { predicate: Binder { value: TraitPredicate(<usize as std::clone::Clone>, polarity:Positive), bound_vars: [] }, param_env: ParamEnv { caller_bounds: [], reveal: UserFacing } }, anchor: Bind(DefId(0:5 ~ main[4f74]::main)), predefined_opaques_in_body: PredefinedOpaques(PredefinedOpaquesData { opaque_types: [] }) }
ROOT RESULT: Ok(Canonical { value: Response { certainty: Yes, var_values: CanonicalVarValues { var_values: [] }, external_constraints: ExternalConstraints(ExternalConstraintsData { region_constraints: QueryRegionConstraints { outlives: [], member_constraints: [] }, opaque_types: [] }) }, max_universe: U0, variables: [] }) {
CANDIDATE Impl(DefId(2:30468 ~ core[d1d7]::clone::impls::{impl#5})): Ok(Canonical { value: Response { certainty: Yes, var_values: CanonicalVarValues { var_values: [] }, external_constraints: ExternalConstraints(ExternalConstraintsData { region_constraints: QueryRegionConstraints { outlives: [], member_constraints: [] }, opaque_types: [] }) }, max_universe: U0, variables: [] }) {
TRY_EVALUATE_ADDED_GOALS: Ok(Yes)
ITERATION 0 {}
}
CANDIDATE constituent tys: Err(NoSolution) {}
NORMALIZING SELF TY FOR ASSEMBLY: {}
NORMALIZING SELF TY FOR ASSEMBLY: {}
}
}
RESULT: Ok(Canonical { value: Response { certainty: Yes, var_values: CanonicalVarValues { var_values: [] }, external_constraints: ExternalConstraints(ExternalConstraintsData { region_constraints: QueryRegionConstraints { outlives: [], member_constraints: [] }, opaque_types: [] }) }, max_universe: U0, variables: [] })
}
```
r? `@BoxyUwU`
|
|
|
|
Merge `collect_mod_item_types` query into `check_well_formed`
follow-up to https://github.com/rust-lang/rust/pull/121154
this removes more potential parallel-compiler bottlenecks and moves diagnostics for the same items next to each other, instead of grouping diagnostics by analysis kind
|
|
Rollup of 8 pull requests
Successful merges:
- #118623 (Improve std::fs::read_to_string example)
- #119365 (Add asm goto support to `asm!`)
- #120608 (Docs for std::ptr::slice_from_raw_parts)
- #121832 (Add new Tier-3 target: `loongarch64-unknown-linux-musl`)
- #121938 (Fix quadratic behavior of repeated vectored writes)
- #122099 (Add `#[inline]` to `BTreeMap::new` constructor)
- #122103 (Make TAITs and ATPITs capture late-bound lifetimes in scope)
- #122143 (PassWrapper: update for llvm/llvm-project@a3319371970b)
Failed merges:
- #122076 (Tweak the way we protect in-place function arguments in interpreters)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Make TAITs and ATPITs capture late-bound lifetimes in scope
This generalizes the behavior that RPITs have, where they duplicate their in-scope lifetimes so that they will always *reify* late-bound lifetimes that they capture. This allows TAITs and ATPITs to properly error when they capture in-scope late-bound lifetimes.
r? `@oli-obk` cc `@aliemjay`
Fixes #122093 and therefore https://github.com/rust-lang/rust/pull/120700#issuecomment-1981213868
|
|
Add asm goto support to `asm!`
Tracking issue: #119364
This PR implements asm-goto support, using the syntax described in "future possibilities" section of [RFC2873](https://rust-lang.github.io/rfcs/2873-inline-asm.html#asm-goto).
Currently I have only implemented the `label` part, not the `fallthrough` part (i.e. fallthrough is implicit). This doesn't reduce the expressive though, since you can use label-break to get arbitrary control flow or simply set a value and rely on jump threading optimisation to get the desired control flow. I can add that later if deemed necessary.
r? ``@Amanieu``
cc ``@ojeda``
|
|
Replace the default branch with an unreachable branch If it is the last variant
Fixes #119520. Fixes #110097.
LLVM currently has limited ability to eliminate dead branches in switches, even with the patch of https://github.com/llvm/llvm-project/issues/73446.
The main reasons are as follows:
- Additional costs are required to calculate the range of values, and there exist many scenarios that cannot be analyzed accurately.
- Matching values by bitwise calculation cannot handle odd branches, nor can it handle values like `-1, 0, 1`. See [SimplifyCFG.cpp#L5424](https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/llvm/lib/Transforms/Utils/SimplifyCFG.cpp#L5424) and https://llvm.godbolt.org/z/qYMqhvMa8
- The current range information is continuous, even if the metadata for the range is submitted. See [ConstantRange.cpp#L1869-L1870](https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/llvm/lib/IR/ConstantRange.cpp#L1869-L1870).
- The metadata of the range may be lost in passes such as SROA. See https://rust.godbolt.org/z/e7f87vKMK.
Although we can make improvements, I think it would be more appropriate to put this issue to rustc first. After all, we can easily know the possible values.
Note that we've currently found a slow compilation problem in the presence of unreachable branches. See
https://github.com/llvm/llvm-project/issues/78578.
r? compiler
|
|
|
|
|
