[v2] Cache type derived data

[ggiraldez]

Builds on top of #1805

Cache all types's internal and canonical names, as well as size in storage.

This info (the internal name in particular) will be needed for diagnostics related to typing, but we can't fully compute the type data until all types have been instantiated at the end of p4. I see three alternatives:

1. do typing diagnostics after p4, and after computing the type data
2. pre-populate the type data cache on demand on p4 so that diagnostics can use it
3. duplicate functions to compute type internal names without caching so they can be used for diagnostics only

[changeset-bot]

⚠️ No Changeset found

Latest commit: 7a92137

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[OmarTawfik]

duplicate functions to compute type internal names without caching so they can be used for diagnostics only

IIUC, this cache is only useful for diagnostics, and it will never be used in the happy path scenario. So, we would be paying the cost of populating it all the time, but rarely actually using it.

Given that our priority is the happy path perf, I wonder if we should hold off on such optimizations for now, until we get real-world perf numbers (e.g. IDE scenarios) to prove it is worth paying the cost upfront.

• Also relates to [v2] Cache contracts' storage layouts (permanent and transient) #1817

[ggiraldez]

This is also used for ABI related information you can get from the AST, and solx is consuming some of it (eg. here and here). However, I agree having this cache is probably not helping performance in most cases (it might if the user code has lots of nested structs or some other edge cases).

I do like the idea of having the computation functions moved and centralized in the semantic crate instead of having some of them there and the rest in ast. For diagnostics we'll probably only need the internal name of types, but agreed that they will not be in the happy path.

Happy to close this (and #1817), or change them to only move the functionality but not construct the caches eagerly.

[OmarTawfik]

I'm fine with the refactoring if you think it is worth doing.
My concern is mainly about adding the cache without having the numbers to verify its impact.