feat: Implement type aliases

[Ethan-000]

Description

Problem*

Resolves #735

Summary*

following #817

also added support for generics

Documentation

• This PR requires documentation updates when merged.

  • I will submit a noir-lang/docs PR.
  • I will request for and support Dev Rel's help in documenting this PR.

Additional Context

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[vezenovm]

The ordering here means we cannot use type aliases inside of struct definitions. While this is valid Rust:

type Bar = u32;

struct myStruct {
    foo: Bar,
}

fn main() {
    let s = myStruct { foo: 10u32 };
    println!("{}", s.foo);
}

[jfecher]

This is name resolution whereas collecting names should be an earlier step before this. We should double check that this use case is working as expected though.

[vezenovm]

Yeah, but if you have a Noir program with the same struct as above:

type Bar = Field;

struct myStruct {
    foo: Bar,
}

you will fail during resolution. When you go to resolve Bar which is a named type, the get_type_alias method will be called and panic with this:

Message:  no entry found for key
Location: crates/noirc_frontend/src/node_interner.rs:560

as the code only pushes to the type_alias map during resolve_type_aliases: https://github.com/noir-lang/noir/pull/2003/files#r1272800709.

With the way resolve_type_aliases is written now the above snippet will pass when it is called before resolve_structs.

[jfecher]

Looks pretty good, I think there are just some smaller changes needed. Most are renamings/style suggestions.

[Ethan-000]

#2003 (comment)

#2003 (comment)

#2003 (comment)

There are the issues remaining

For the second one, I don't know if theres a way to solve it 🥲. open to suggestions and ideas.
cus each time resolve_type_aliases(unresolved_typ.type_alias_def) is called, it has to resolve to a Type and type Three = Two<u8> definitions are not in order so if it tries to solve this before Two<u8> is solved it won't be able to do it.

For the third one, Struct seems to be treated as a module, not sure how to do it similarly with TypeAlias

[Ethan-000]

huh .. its working today
no idea why

[vezenovm]

huh .. its working today
no idea why

Did you test it before pushing the empty definition inside the collector rather than the resolver?

[Ethan-000]

huh .. its working today
no idea why

Did you test it before pushing the empty definition inside the collector rather than the resolver?

seems to be solved by this 649ed8a

I didn't change it to Type::Error to solve the issue though. just tried it randomly and it worked 🫠

[jfecher]

@Ethan-000 maybe its a result of resolution order being random (#1122)?

It might fail some times and succeed on others.

[Ethan-000]

@Ethan-000 maybe its a result of resolution order being random (#1122)?

It might fail some times and succeed on others.

yep the resolution being random is causing the problem
ideally it should solve One first then Two and Three
solving Three before One caused Three to be solved as the dummy Type put into the empty definition

I was expecting changing it to Type::Error will result Three to be solved to Type::Error if it is solved before One but its working now

[jfecher]

I think I'm alright with merging this with the random struct/type order bug since that is an already-filed and separate issue from type aliases.

[Ethan-000]

here

[jfecher]

You have self and thus a mutable reference to the dfg so you can use that to return a mutable reference to the type alias.

[Ethan-000]

I can't seem to make this work. if I understand correctly, it says |arg| already takes mutable reference and type_alias_type.to_string(), is taking it twice

[Ethan-000]

closure requires unique access to `*self` but it is already borrowed
closure construction occurs hererustc[Click for full compiler diagnostic](rust-analyzer-diagnostics-view:/diagnostic%20message%20%5B2%5D?2#file%3A%2F%2F%2FUsers%2Fethan000%2Fcode%2Faztec%2Fforks%2Fnoir%2Fcrates%2Fnoirc_frontend%2Fsrc%2Fhir%2Fresolution%2Fresolver.rs)
resolver.rs(401, 40): borrow occurs here
resolver.rs(402, 47): second borrow occurs due to use of `*self` in closure
resolver.rs(403, 42): first borrow later used here

[jfecher]

You can't borrow self mutably and immutably, so there are two approaches you could take and both are different methods of changing it to not borrow self. The first is that you could replace self in the closure with this and pass this in as a parameter. The second approach would be to make it into a free function rather than a closure. I think there are few enough closed-over values that this may be the cleaner approach.

[Ethan-000]

ok this error message is not super useful. I think the problem is that args is part of type alias that the function is trying to solve and self.lookup_type_alias(path.clone()) takes the same type_aliase so if a reference is used self.resolve_type_inner(arg, new_variables) will take ownership and type_alias_type.to_string() can't use the reference. uhh don't know if I understand this correctly or not. do u mind modifying it directly to the code you are thinking if theres are better way to do this 🥲

[jfecher]

I've reworked it but can't push the changes to this PR (or suggest them - since it is across multiple files), so I've opened a new PR here: #2112

[jfecher]

I've opened #2112 to address the comments on this PR

[Ethan-000]

Many thanks for the review and help ^