remove MutTy

[cyrgani]

This PR removes ast::MutTy and hir::MutTy and inlines their two fields directly into their corresponding TypeKind variants. These types probably made sense in pre-1.0 versions where it still had a syntax-level representation with things like [mut T]. Nowadays, it is just a type that is used in some, but not all places to group a type and a mutability together (for example, rustc_type_ir does not include such a wrapper). It also has no methods and just makes some match statements more verbose. Removing it makes them more readable.

[rustbot]

The parser was modified, potentially altering the grammar of (stable) Rust
which would be a breaking change.

cc @fmease

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

clippy is developed in its own repository. If possible, consider making this change to rust-lang/rust-clippy instead.

cc @rust-lang/clippy

rustfmt is developed in its own repository. If possible, consider making this change to rust-lang/rustfmt instead.

cc @rust-lang/rustfmt

Some changes occurred in compiler/rustc_builtin_macros/src/autodiff.rs

cc @ZuseZ4

HIR ty lowering was modified

cc @fmease

Some changes occurred in compiler/rustc_ast/src/expand/autodiff_attrs.rs

cc @ZuseZ4

[rustbot]

r? @mejrs

rustbot has assigned @mejrs.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 77 candidates
• Random selection from 21 candidates

[oli-obk]

Huh I thought we had this before and changed at some point to bundle the pointer with its mutability. Or was that only in TyKind?

Either way, we should keep all three in sync, so also do the change for TyKind::Ref and Ptr, or keep all three in the MutTy system.

[cyrgani]

It was removed from rustc_type_ir with #122852 and rust-lang/types-team#124.

[mejrs]

Overall the change looks good to me.

I have two thoughts about this (and please disagree if you disagree)

There are many changes like

- let TyKind::Ptr(_) = ret_ty.kind
+ let TyKind::Ptr(..) = ret_ty.kind

The downside of this is that it'll continue to compile if we add or remove fields in the future. It is more robust to do:

- let TyKind::Ptr(_) = ret_ty.kind
+ let TyKind::Ptr(_, _) = ret_ty.kind

(same for the Ref types)

Second, there a couple of cases where this happens:

let ty =...;

let Ptr(ty, _) = ty.kind

// ty is used later

It is rather error prone to alias variables of a same type in this manner. Usually, but not always, the code here chooses a different name to get around this. Can you choose one convention and apply it everywhere? Can be something like pointee_ty, ref_ty, inner_ty, etc, I don't really care about which one.

View changes since this review

[cyrgani]

Regarding 1., I don't see this as much of a downside. It would make refactorings like this one easier and I would expect that if a new field was to be added or removed, these places would mostly not care and ignore the field as well. (And there are already several preexisting cases of Ptr(..) and Ref(..).)

Regarding 2., I'll change this tomorrow.

[cyrgani]

why was this extra whitespace neither detected by x fmt nor in CI?

View changes since the review

[mejrs]

X doesn't format clippy, you have to navigate to the clippy folder and use cargo dev fmt

[cyrgani]

I've changed all the potentially ambiguous ty variable names to inner_ty (except in one case where another variable named inner_ty also already existed; I called it ref_ty there instead).

[mejrs]

@bors r+ rollup=iffy

View changes since this review

[rust-bors]

📌 Commit ac6f00d has been approved by mejrs

It is now in the queue for this repository.