feat(fmt): lsp hover #4923
feat(fmt): lsp hover #4923
Conversation
CodSpeed Performance ReportMerging #4923 will not alter performanceComparing Summary
|
WASM Query Engine file Size
|
…r actually returned as a valid variant, so now it is. Made `iter_tops` on walkers public. Unsure if there's a better way about this; it seemed the most convenient for right now. Added a helper to FieldType to retrieve names. Further clean-up of hover
use topwalker
remove dbg
Show field doc on hover of model and composite field names add conversion methods to enum / composite type scalar fields for composite type field walker general cleanup
hover enum value + doc
… relation that is broken
* remove early bailout in parser db * We can no longer assume that relation fields exist as the opposite side of the relation might not exist yet. * Added refine_known for usage in QE; refine is now optional as we cannot guarantee a field is either a scalar or relation outside of the QE --------- Co-authored-by: Sergey Tatarintsev <[email protected]>
| /// ! Commenting this yields a panic | ||
| /// ! thread 'hover::tests::model_from_model_type_broken_relations' panicked at | ||
| /// ! psl/parser-database/src/walkers/relation_field.rs:120:36: | ||
| /// ! no entry found for key | ||
| // model Forum { | ||
| // id Int @id | ||
| // name String | ||
| // Post interm[] | ||
| // } |
There was a problem hiding this comment.
Can you elaborate as to why it panics?
There was a problem hiding this comment.
Ah good catch, this no-longer panics due to the parser database changes.
So, what used to happen was as we were building up the parser database, if we saw validation errors in the schema, we'd bailout early. The problem there was that everything using the parser database assumed that information was correct and available. This lead to indexing on things that could not exist yielding panics.
I'm going to remove the commented out model and text as this schema is now be parseable 👍
| }, | ||
| walkers::RefinedFieldWalker::Relation(rf) => { | ||
| let opposite_model = rf.related_model(); | ||
| let relation_info = rf.opposite_relation_field().map(|rf| (rf, rf.ast_field())); |
There was a problem hiding this comment.
Can you explain when the opposite_relation_field may be None? I'm trying to understand when would format_relation_info return empty strings
There was a problem hiding this comment.
Lets say we have the following schema
model interm {
id Int @id
forumId Int
forum Forum @relation(fields: [forumId], references: [id])
}
/// Forum Doc
model Forum {
id Int @id
}The opposite relation is yet to be defined in the model Forum but we still want to be able to hover over where it's used as a field type in interm and see it's model documentation
prisma-fmt/tests/hover/test_api.rs
Outdated
There was a problem hiding this comment.
I see we keep c&p'ing this test runner. I'm not necessarily asking you to take action, but thinking about ways to dry this would be great. Things like take_cursor, take_cursor_one, and format_chunk.
There was a problem hiding this comment.
Yeah, no, this is one that I'm already thinking about 😓 I want to reduce this but didn't want to mess with it for this pr
added test for embedded m2n in mongodb Co-authored-by: Flavian Desverne <[email protected]>
* Moves hover impl to engines, for further details: prisma/prisma-engines#4923
Screen.Recording.2024-06-14.at.20.27.12.mov
Screen.Recording.2024-06-15.at.03.48.47.mov
related: https://github.com/prisma/team-orm/issues/1202
closes: prisma/language-tools#1172