chore(frontend): Avoid silent fallback when returning turbofish generics for primitive types

[vezenovm]

Description

Problem*

Working towards the audit of the elaborator group 7a

I noticed that in resolve_item_turbofish_and_self_type we deconstruct the resolved primitive type to fetch any possible generics as they are used later in the elaboration flow. The logic is currently correct but could be incorrect if we ever add another primitive type with generics and forget to return its generics after instantiating the type.

Summary*

When instantiating a primitive type with turbofish we now also return a bool as to whether that type should have generics. That bool then determines whether we return an empty list of generics, not the instantiated type. Now if we were to add another primitive type with generics and not return any generics, we would hit the new panic added in this PR.

I thought about just adding a has_generics helper on PrimitiveType but this felt like we then still have two sources of truth when removing that is the goal of this refactor. We would have to remember to update this helper if we added a new primitive type.

Additional Context

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

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

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Test Suite Duration'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: 89ee869	Previous: 4a6d6f9	Ratio
test_report_zkpassport_noir-ecdsa_	3 s	2 s	1.50

This comment was automatically generated by workflow using github-action-benchmark.

CC: @TomAFrench

[asterite]

Nice! Maybe we could return a Vec or Option<Vec> with the generics (instead of the bool)? That way we don't have to repeat checking the actual type later on. It might be a bit more expensive, but likely not something noticeable.

[vezenovm]

Maybe we could return a Vec or Option<Vec> with the generics (instead of the bool)? That way we don't have to repeat checking the actual type later on. It might be a bit more expensive, but likely not something noticeable.

I had thought about doing that as well. We would have to clone the types but we could remove the need to deconstruct the result type at all. Do you prefer that to this?

[asterite]

Do you prefer that to this?

Yes, or at least it would make it harder to forget if we eventually add a new generic type.

[asterite]

Ah, actually, there's an unreachable if we forget to handle that case, so no need to change anything 👍

[vezenovm]

Ah, actually, there's an unreachable if we forget to handle that case, so no need to change anything 👍

Yeah without the unreachable we would still have a silent fallback. I will keep the type deconstruction as that is what we already have and we can avoid cloning when we don't need to (this method is also used in resolve_type_trait_method which just wants the entire type).

[vezenovm]

@asterite could I get an approval or do you think we should still switch to the cloned type method?

[asterite]

Sorry! I thought I had approved.