Use stable metric for const eval limit instead of current terminator-based logic
This patch adds a `MirPass` that inserts a new MIR instruction `ConstEvalCounter` to any loops and function calls in the CFG. This instruction is used during Const Eval to count against the `const_eval_limit`, and emit the `StepLimitReached` error, replacing the current logic which uses Terminators only.
The new method of counting loops and function calls should be more stable across compiler versions (i.e., not cause crates that compiled successfully before, to no longer compile when changes to the MIR generation/optimization are made).
Also see: #103877
remove unnecessary check for opaque types
this isn't needed and may hide some errors.
after analysis there are no opaque types so it's a noop anyways
before analysis there are opaque types but due to `Reveal::UserFacing` we don't reveal them. `is_subtype` simply discards the opaque type constraints as these will get checked again during mir borrowck.
r? types
want to land this after the beta-cutoff as mir validator changes are apparently pretty scary
This patch adds a `MirPass` that tracks the number of back-edges and
function calls in the CFG, adds a new MIR instruction to increment a
counter every time they are encountered during Const Eval, and emit a
warning if a configured limit is breached.
use LocalDefId instead of HirId in trait resolution to simplify
the obligation clause resolution
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Combine `ty::Projection` and `ty::Opaque` into `ty::Alias`
Implements https://github.com/rust-lang/types-team/issues/79.
This PR consolidates `ty::Projection` and `ty::Opaque` into a single `ty::Alias`, with an `AliasKind` and `AliasTy` type (renamed from `ty::ProjectionTy`, which is the inner data of `ty::Projection`) defined as so:
```
enum AliasKind {
Projection,
Opaque,
}
struct AliasTy<'tcx> {
def_id: DefId,
substs: SubstsRef<'tcx>,
}
```
Since we don't have access to `TyCtxt` in type flags computation, and because repeatedly calling `DefKind` on the def-id is expensive, these two types are distinguished with `ty::AliasKind`, conveniently glob-imported into `ty::{Projection, Opaque}`. For example:
```diff
match ty.kind() {
- ty::Opaque(..) =>
+ ty::Alias(ty::Opaque, ..) => {}
_ => {}
}
```
This PR also consolidates match arms that treated `ty::Opaque` and `ty::Projection` identically.
r? `@ghost`
Prefer doc comments over `//`-comments in compiler
Doc comments are generally nicer: they show up in the documentation, they are shown in IDEs when you hover other mentions of items, etc. Thus it makes sense to use them instead of `//`-comments.
Pretty-print generators with their `generator_kind`
After removing `GenFuture`, I special-cased async generators to pretty-print as `impl Future<Output = X>` mainly to avoid too much diagnostics changes originally.
This now reverses that change so that async fn/blocks are pretty-printed as `[$async-type@$source-position]` in various diagnostics, and updates the tests that this touches.
After removing `GenFuture`, I special-cased async generators to pretty-print as `impl Future<Output = X>` mainly to avoid too much diagnostics changes originally.
This now reverses that change so that async fn/blocks are pretty-printed as `[$movability `async` $something@$source-position]` in various diagnostics, and updates the tests that this touches.
