`Type` getters could automatically unwrap user types

[xermicus]

Currently it's super easy to write code that forgets to unwrap user types. I think that for most cases, we want to work with the actual type and not the user type.

There are many places which this could potentially matter:

src/codegen/cfg.rs
2131:    pub fn storage_type(&self) -> Type {
2140:    pub fn value_type(&self) -> Type {

src/codegen/mod.rs
799:    fn ty(&self) -> Type {

src/sema/ast.rs
125:    fn ty(&self) -> Type;

src/sema/yul/ast.rs
50:    fn ty(&self) -> Type {

src/sema/expression/retrieve_type.rs
6:    fn ty(&self) -> Type {

What we could do is to use unwrap_user_type() in all these fn ty(). However, a consistent solution to this could be to make the enum Type private, and provide a wrapper for it, that explicitly represents the Type in its wrapped or unwrapped form. This would force us to think about this nuance wherever enum Type is currently used.

WDYT?

[LucasSte]

Ideally, a user type should not exist in codegen. We would unwrap it when building the CFG.

[xermicus]

I agree, however I'm not sure how to enforce this without having two entirely distinct Type types within the two modules.

[seanyoung]

Ideally, a user type should not exist in codegen. We would unwrap it when building the CFG.

How would we add correct debug information to types if the higher level user-type information has been thrown away? I don't think removing the user-types from the CFG is the solution.