feat(core): add light version of the semantic model to scanner #5599
Conversation
github-actions
bot
added
A-Project
CodSpeed Performance ReportMerging #5599 will not alter performanceComparing Summary
|
| /// A `let` or `const` declaration. | ||
| /// | ||
| /// The type (either declared or inferred) of the value. |
There was a problem hiding this comment.
nit: We should add var and using too :) or make the docs a bit more generic
There was a problem hiding this comment.
var is covered under HoistedValue instead. using isn't covered yet, but also makes no sense in the context of exports, I think.
|
|
||
| impl JsDeclarationKind { | ||
| /// Returns `true` for any declaration that _may_ be a type. | ||
| fn might_be_type(&self) -> bool { |
There was a problem hiding this comment.
I fail to understand the semantic difference between "might be a type" (might_be_type) and "is a type" (is_a_type), because a "might" could be translated into a enum where "maybe" is a valid variant.
There was a problem hiding this comment.
It's mainly due to the presence of the Import variant, where we don't know whether it's a type or a value being imported.
I'll clarify it with a comment.
arendjr
force-pushed
the
js-semantic-model-light
branch
from
9029e92 to
968b6cf
Compare
Summary
Fixes #5312.
This adds a light, and as of yet incomplete, version of the semantic model to the scanner. The goal isn't yet to do deep semantic analysis inside the scanned modules, but simply to resolve exported symbols when their declaration is in a different position than the export statement itself.
This makes sure that we can resolve both types and JSDoc comments more accurately through the module graph, and also resolves one of the limitations of
noPrivateImportsthat we had in the beta.JSDoc comments also have a dedicated type. The type definitions for type aliases has been refined as well.
Test Plan
Tests added and snapshots updated.