| Age | Commit message (Collapse) | Author | Lines |
|---|
|
As is already done in several other crates, such as `rustc_errors`.
|
|
|
|
Uplift `RegionVid`, `TermKind` to `rustc_type_ir`, and `EagerResolver` to `rustc_next_trait_solver`
- Uplift `RegionVid`. This was complicated due to the fact that we implement `polonius_engine::Atom` for `RegionVid` -- but I just separated that into `PoloniusRegionVid`, and added `From`/`Into` impls so it can be defined in `rustc_borrowck` separately. Coherence 😵
- Change `InferCtxtLike` to expose `opportunistically_resolve_{ty,ct,lt,int,float}_var` so that we can uplift `EagerResolver` for use in the canonicalization methods.
- Uplift `TermKind` much like `GenericArgKind`
All of this is miscellaneous dependencies for making more `EvalCtxt` methods generic.
|
|
report_return_mismatched_types
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove `Rvalue::CheckedBinaryOp`
Zulip conversation: <https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/intrinsics.20vs.20binop.2Funop/near/438729996>
cc `@RalfJung`
While it's a draft,
r? ghost
|
|
coverage: Memoize and simplify counter expressions
When creating coverage counter expressions as part of coverage instrumentation, we often end up creating obviously-redundant expressions like `c1 + (c0 - c1)`, which is equivalent to just `c0`.
To avoid doing so, this PR checks when we would create an expression matching one of 5 patterns, and uses the simplified form instead:
- `(a - b) + b` → `a`.
- `(a + b) - b` → `a`.
- `(a + b) - a` → `b`.
- `a + (b - a)` → `b`.
- `a - (a - b)` → `b`.
Of all the different ways to combine 3 operands and 2 operators, these are the patterns that allow simplification.
(Some of those patterns currently don't occur in practice, but are included anyway for completeness, to avoid having to add them later as branch coverage and MC/DC coverage support expands.)
---
This PR also adds memoization for newly-created (or newly-simplified) counter expressions, to avoid creating duplicates.
This currently makes no difference to the final mappings, but is expected to be useful for MC/DC coverage of match expressions, as proposed by https://github.com/rust-lang/rust/pull/124278#issuecomment-2106754753.
|
|
Check whether the next_node is else-less if in get_return_block
Fix #124819
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #124948 (chore: Remove repeated words (extension of #124924))
- #124992 (Add example to IsTerminal::is_terminal)
- #125279 (make `Debug` impl for `Term` simpler)
- #125286 (Miri subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
generics' attributes
|
|
Uplift more query stuff
- Uplift various query input/response internals
- Uplift the `ProofTree` structures and make the `ProofTreeBuilder` stuff (mostly) generic over `Interner`
- Stop using `TyCtxt::def_kind` in favor of `AliasTerm::kind`
r? lcnr
|
|
|
|
and make NestedGoals generic
|
|
Rename Unsafe to Safety
Alternative to #124455, which is to just have one Safety enum to use everywhere, this opens the posibility of adding `ast::Safety::Safe` that's useful for unsafe extern blocks.
This leaves us today with:
```rust
enum ast::Safety {
Unsafe(Span),
Default,
// Safe (going to be added for unsafe extern blocks)
}
enum hir::Safety {
Unsafe,
Safe,
}
```
We would convert from `ast::Safety::Default` into the right Safety level according the context.
|
|
This mostly reverts commit 7449478c2f6fd2d72c12a51d8562f1e6108facab.
It also removes an `opt_param_at` that really is unnecessary given our
ICE policy for malformed intrinsics.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
MIR operators: clarify Shl/Shr handling of negative offsets
"made unsigned" was not fully clear (made unsigned how? by using `abs`? no), so let's say "re-interpreted as an unsigned value of the same size" instead.
r? `@scottmcm`
|
|
|
|
coverage: `CoverageIdsInfo::mcdc_bitmap_bytes` is never needed
This code for recalculating `mcdc_bitmap_bytes` in a query doesn't provide any benefit, because its result won't have changed from the value in `FunctionCoverageInfo` that was computed during the MIR instrumentation pass.
Extracted from #124571, to avoid having this held up by unrelated issues with condition count checks.
`@rustbot` label +A-code-coverage
|
|
r=compiler-errors
Also expand weak alias tys inside consts inside `expand_weak_alias_tys`
Ever since #121344 has been merged, I couldn't let go of the fear that I might've slipped a tiny bug into rustc (:P).
Checking the type flags of the `Const` is strictly more correct than only checking the ones of the `Const`'s `Ty`. I don't think it's possible to trigger an ICE rn (i.e., one of the two `bug!("unexpected weak alias type")` I added in branches where `expand_weak_alias_tys` should've expanded *all* weak alias tys) because presently const exprs aren't allowed to capture late-bound vars. To be future-proof however, we should iron this out.
A possible reproducer would be the following if I'm not mistaken (currently fails to compile due to the aforementioned restriction):
```rs
#![feature(lazy_type_alias, adt_const_params, generic_const_exprs)]
type F = for<'a> fn(A<{ S::<Weak<'a>>(loop {}) }>) -> &'a ();
type A<const N: S<Weak<'static>>> = ();
#[derive(PartialEq, Eq, std::marker::ConstParamTy)]
struct S<T>(T);
type Weak<'a> = &'a ();
```
Whether a late-bound region should actually be considered constrained by a const expr is a separate question — one which we don't need to answer until / unless we actually allow them in such contexts (probable answer: only inside the return exprs of a block but not inside the stmts).
r? oli-obk (he's not available rn but that's fine) or types or compiler
|
|
Uplift `AliasTy` and `AliasTerm`
Follow-up from #125076.
r? lcnr
|
|
These comments appear to be inspired by the similar comments on
`CounterIncrement` and `ExpressionUsed`. But those comments refer to specific
simplification steps performed during coverage codegen, and there is no
corresponding step for the MC/DC coverage statements.
If these statements do not survive optimization, they will simply not
participate in code generation, just like any other statement.
|
|
This code for recalculating `mcdc_bitmap_bytes` doesn't provide any benefit,
because its result won't have changed from the value in `FunctionCoverageInfo`
that was computed during the MIR instrumentation pass.
|
|
|
|
This currently has no effect, but is expected to be useful when expanding
support for branch coverage and MC/DC coverage.
|
|
|
|
|
|
Split out `ty::AliasTerm` from `ty::AliasTy`
Splitting out `AliasTerm` (for use in project and normalizes goals) and `AliasTy` (for use in `ty::Alias`)
r? lcnr
|
|
|
|
|
|
Many, many projects use `size_of` to get the size of a type. However,
it's also often equally easy to hardcode a size (e.g. `8` instead of
`size_of::<u64>()`). Minimizing friction in the use of `size_of` helps
ensure that people use it and make code more self-documenting.
The name `size_of` is unambiguous: the name alone, without any prefix or
path, is self-explanatory and unmistakeable for any other functionality.
Adding it to the prelude cannot produce any name conflicts, as any local
definition will silently shadow the one from the prelude. Thus, we don't
need to wait for a new edition prelude to add it.
Add `size_of_val`, `align_of`, and `align_of_val` as well, with similar
justification: widely useful, self-explanatory, unmistakeable for
anything else, won't produce conflicts.
|
|
|
|
Remove `#[macro_use] extern crate rustc middle` from numerous crates
Because explicit importing of macros via `use` items is nicer (more standard and readable) than implicit importing via `#[macro_use]`. This PR mops up some cases I didn't get to in #124511.
r? `@saethlin`
|
|
This requires exporting the interpreter macros so they can be used with
`use crate::interpret::*`.
|
