Migrate mir_build diagnostics 2 of 3
The first three commits are fairly boring, however I've made some changes to the output of the match checking diagnostics.
Rename `hir::Map::{get_,find_}parent_node` to `hir::Map::{,opt_}parent_id`, and add `hir::Map::{get,find}_parent`
The `hir::Map::get_parent_node` function doesn't return a `Node`, and I think that's quite confusing. Let's rename it to something that sounds more like something that gets the parent hir id => `hir::Map::parent_id`. Same with `find_parent_node` => `opt_parent_id`.
Also, combine `hir.get(hir.parent_id(hir_id))` and similar `hir.find(hir.parent_id(hir_id))` function into new functions that actually retrieve the parent node in one call. This last commit is the only one that might need to be looked at closely.
Clarify that raw retags are not permitted in Mir
Not sure when this changed, but documentation and the validator needed to be updated. This also removes raw retags from custom mir.
cc rust-lang/miri#2735
r? `@RalfJung`
Improve syntax of `newtype_index`
This makes it more like proper Rust and also makes the implementation a lot simpler.
Mostly just turns weird flags in the body into proper attributes.
It should probably also be converted to an attribute macro instead of function-like, but that can be done in a future PR.
Remove the `..` from the body, only a few invocations used it and it's
inconsistent with rust syntax.
Use `;` instead of `,` between consts. As the Rust syntax gods inteded.
Migrate rustc_mir_build diagnostics
Rebases https://github.com/rust-lang/rust/pull/100854
~~The remaining issue is how to better resolve 72bea68af4~~
~~The diagnostic macros seems to generate a broken diagnostic, and I couldn't figure out how to manually format the fluent message, so I hardcoded the format string for now. I'd like pointers to a better fix for this.~~
Also, I'm not 100% sure I didn't mess up a rebase somewhere 🙂
r? `@davidtwco`
Support call and drop terminators in custom mir
The only caveat with this change is that cleanup blocks are not supported. I would like to add them, but it's not quite clear to me what the best way to do that is, so I'll have to think about it some more.
r? ``@oli-obk``
Custom MIR: Many more improvements
Commits are each atomic changes, best reviewed one at a time, with the exception that the last commit includes all the documentation.
### First commit
Unsafetyck was not correctly disabled before for `dialect = "built"` custom MIR. This is fixed and a regression test is added.
### Second commit
Implements `Discriminant`, `SetDiscriminant`, and `SwitchInt`.
### Third commit
Implements indexing, field, and variant projections.
### Fourth commit
Documents the previous commits and everything else.
There is some amount of weirdness here due to having to beat Rust syntax into cooperating with MIR concepts, but it hopefully should not be too much. All of it is documented.
r? `@oli-obk`
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`
Change pattern borrowing suggestions to be verbose and remove invalid suggestion
Synthesize a more accurate span and use verbose suggestion output to
make the message clearer.
Do not suggest borrowing binding in pattern in let else. Fix#104838.
Allow unsafe through inline const
Handle similar to closures.
Address https://github.com/rust-lang/rust/pull/104087#issuecomment-1324173328
Note that this PR does not fix the issue for `unsafe { [0; function_requiring_unsafe()] }`. This is fundamentally unfixable for MIR unsafeck IMO.
This PR also does not fix unsafety checking for inline const in pattern position. It actually breaks it, allowing unsafe functions to be used in inline const in pattern position without unsafe blocks. Inline const in pattern position is not visible in MIR so ignored by MIR unsafety checking (currently it is also not checked by borrow checker, which is the reason why it's considered an incomplete feature).
`@rustbot` label: +T-lang +F-inline_const
Remove `token::Lit` from `ast::MetaItemLit`.
Currently `ast::MetaItemLit` represents the literal kind twice. This PR removes that redundancy. Best reviewed one commit at a time.
r? `@petrochenkov`
compiler: remove unnecessary imports and qualified paths
Some of these imports were necessary before Edition 2021, others were already in the prelude.
I hope it's fine that this PR is so spread-out across files :/
This is required to distinguish between cooked and raw byte string
literals in an `ast::LitKind`, without referring to an adjacent
`token::Lit`. It's a prerequisite for the next commit.
`mk_const(ty::ConstKind::X(...), ty)` can now be simplified to
`mk_cosnt(..., ty)`.
I searched with the following regex: \mk_const\([\n\s]*(ty::)?ConstKind\
I've left `ty::ConstKind::{Bound, Error}` as-is, they seem clearer this
way.
Use `as_deref` in compiler (but only where it makes sense)
This simplifies some code :3
(there are some changes that are not exacly `as_deref`, but more like "clever `Option`/`Result` method use")
Only declare bindings for if-let guards once per arm
Currently, each candidate for a match arm uses separate locals for the bindings in the if-let guard, causing problems (#88015) when those branches converge in the arm body.
Fixes#88015 (🤞)
Record `LocalDefId` in HIR nodes instead of a side table
This is part of an attempt to remove the `HirId -> LocalDefId` table from HIR.
This attempt is a prerequisite to creation of `LocalDefId` after HIR lowering (https://github.com/rust-lang/rust/pull/96840), by controlling how `def_id` information is accessed.
This first part adds the information to HIR nodes themselves instead of a table.
The second part is https://github.com/rust-lang/rust/pull/103902
The third part will be to make `hir::Visitor::visit_fn` take a `LocalDefId` as last parameter.
The fourth part will be to completely remove the side table.
Reduce span of let else irrefutable_let_patterns warning
Huge spans aren't good for IDE users as they underline constructs that are possibly multiline.
Similar PR to #90761 which did the same for the `unused_macros` lint.
Make `dyn*` casts into a coercion, allow `dyn*` upcasting
I know that `dyn*` is likely not going to be a feature exposed to surface Rust, but this makes it slightly more ergonomic to write tests for these types anyways. ... and this was just fun to implement anyways.
1. Make `dyn*` into a coercion instead of a cast
2. Enable `dyn*` upcasting since we basically get it for free
3. Simplify some of the cast checking code since we're using the coercion path now
r? `@eholk` but feel free to reassign
cc `@nikomatsakis` and `@tmandry` who might care about making `dyn*` casts into a coercion
Suppress irrefutable let patterns lint for prefixes in match guards
In match guards, irrefutable prefixes might use the bindings created by the match pattern. Ideally, we check for this, but we can do the next best thing and just not lint for irrefutable prefixes in match guards.
Fixes#98361
More dupe word typos
I only picked those changes (from the regex search) that I am pretty certain doesn't change meaning and is just a typo fix. Do correct me if any fix is undesirable and I can revert those. Thanks.
In match guards, irrefutable prefixes might use the bindings created
by the match pattern. Ideally, we check for this, but we can do the
next best thing and just not lint for irrefutable prefixes in match
guards.
