psl: don't crash in ModelWalker after name or type validation errors

[aqrln]

Problem description

Fixes: prisma/language-tools#1466

The cause of the problem is that the LSP code action for adding the missing @map attribute for MongoDB relies on the parser database being populated to be able to search for the primary key of the model. However, the parser database constructor returns early when there are validation errors during name and types resolution, so trying to access model attributes later on leads to runtime errors as those structures are not constructed.

There are multiple possible options we could do here:

1. Skip the code action for the @map attribute when there are any other validation errors

We could iterate over the validation errors in the whole document and skip code_actions::mongodb::add_at_map if there is no relevant validation errors before trying to access the model attributes and check the validation errors for a specific span corresponding to the primary field. This might be okay as a hotfix, but would not fundamentally solve the problem and we could run into this again in new code actions we implement.

2. Resolving attributes and relations regardless of validation errors

One option might have been removing early returns and fully populating the parser database, however doing that naively would not work as those early returns are not just an optimization: further validation passes rely on types being valid, and may crash otherwise:

failures:

---- attributes::composite_index::pointing_to_a_non_existing_type stdout ----
thread 'attributes::composite_index::pointing_to_a_non_existing_type' panicked at 'called `Option::unwrap()` on a `None` value', psl/parser-database/src/attributes.rs:632:26
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

---- attributes::relations::relations_negative::relation_field_in_composite_type_errors stdout ----
thread 'attributes::relations::relations_negative::relation_field_in_composite_type_errors' panicked at 'no entry found for key', psl/parser-database/src/attributes.rs:44:49


failures:
    attributes::composite_index::pointing_to_a_non_existing_type
    attributes::relations::relations_negative::relation_field_in_composite_type_errors

Doing that in a safe way might be possible but would require non-trivial changes in the validation code, and would require further validation passes to not assume the previous ones were successful. I don't have enough context about the validation logic to assess if it's viable.

An upside of this approach would be having more complete validation errors, as multiple problems of different types would be highlighted at the same time. Currently some validation errors will only be reported after fixing other ones.

3. Populating the parser database with stub default values

Instead of trying to eliminate the early returns, we could populate the model attributes with stub default values before returning. As no further validation will happen, and the engines do not work with invalid schemas, this should not lead to incorrect behaviour. However, the code in the language tools should take into account that accessing the model attributes in invalid schemas, although won't lead to crashes anymore, will return incomplete information.

4. Handling missing model attributes in ModelWalker

It's possible to check if model attributes for a model exist in the model_attributes hash map before accessing them, and if not, either construct the default value (this would require returning a Cow instead of a reference, which would impact, e.g., unique_criterias method by forcing it to allocate memory where it previously didn't have to, making the code less efficient) or return a None (changing the contract to return Option there and maybe in some downstream methods to offset the burden of handing this case to the caller would be efficient but would make the API way less ergonomic).

Description of the changes

This PR implements the option 3 by adding the default stubs for model and enum attributes in case of name and type resolution errors, as well as regression tests on the prisma-fmt side.

Fixes: prisma/language-tools#1466

[codspeed-hq]

CodSpeed Performance Report

Merging #4087 will not alter performance

_{Comparing fix-prisma-fmt-crash (0daf024) with main (4b132e0)}

Summary

✅ 11 untouched benchmarks

[miguelff]

Option 3 looks the most convenient among the ones you thought of to me as well, and the implementation looks good. 👍🏾

[aqrln]

@miguelff I renamed populate_empty_attributes to create_default_attributes as I think that's a bit better name (it's not exactly clear on the second thought what "empty" meant here).