Rather than de-duplicating results as we build them, a final de-duplication can be done at the end.
This way, there's no forgetting to de-duplicate results at some level.
Prior to this commit, results from template locations that mapped to
multiple different typescript locations would not be de-duplicated (e.g.
an input binding that is bound to two separate directives).
PR Close#40523
When `checkTypeOfPipes` is set to `false`, our TCB currently generates
the a statement like the following when pipes appear in the template:
`(_pipe1 as any).transform(args)`
This did enable us to get _some_ information from the Language Service
about pipes in this case because we still had access to the pipe
instance. However, because it is immediately cast to `any`, we cannot
get type information about the transform access. That means actions like "go to
definition", "find references", "quick info", etc. will return
incomplete information or fail altogether.
Instead, this commit changes the TCB to generate `(_pipe1.transform as any)(args)`.
This gives us the ability to get complete information for the LS
operations listed above.
PR Close#40523
This commit updates the logic in the LS renaming to handle renaming of
pipes, both from the name expression in the pipe metadata as well as
from the template.
The approach here is to introduce a new concept for renaming: an
"indirect" rename. In this type of rename, we find rename locations
in with the native TS Language Service using a different node than the
one we are renaming. Using pipes as an example, if we want to rename the
pipe name from the string literal expression, we use the transform
method to find rename locations rather than the string literal itself
(which will not return any results because it's just a string).
So the general approach is:
* Determine the details about the requested rename location, i.e. the
targeted template node and symbol for a template rename, or the TS
node for a rename outside a template.
* Using the details of the location, determine if the node is attempting
to rename something that is an indirect rename (pipes, selectors,
bindings). Other renames are considered "direct" and we use whatever
results the native TSLS returns for the rename locations.
* In the case of indirect renames, we throw out results that do not
appear in the templates (in this case, the shim files). These results will be
for the "indirect" rename that we don't want to touch, but are only
using to find template results.
* Create an additional rename result for the string literal expression
that is used for the input/output alias, the pipe name, or the
selector.
Note that renaming is moving towards being much more accurate in its
results than "find references". When the approach for renaming
stabilizes, we may want to then port the changes back to being shared
with the approach for retrieving references.
PR Close#40523
This commit renames the files for the references and rename functionality to indicate
that they deal with _both_ references and rename, not just references.
PR Close#40523
This adds string literals, number literals, `true`, `false`, `null` and
`undefined` to autocomplete results in templates.
For example, when completing an input of union type.
Component: `@Input('input') input!: 'a'|'b'|null;`
Template: `[input]="|"`
Provide `'a'`, `'b'`, and `null` as autocompletion entries.
Previously we did not include literal types because we only included
results from the component context (`ctx.`) and the template scope.
This is the second attempt at this. The first attempt is in
1d12c50f63 and it was reverted in 75f881e078150b0d095f2c54a916fc67a10444f6.
PR Close#41645
With this commit, the language service will first try to locate a
pre-compiled style file with the same name when a `css` is provided in
the `styleUrls`. This prevents a missing resource diagnostic for when the
compiled file is not available in the language service environment and also
allows "go to definition" to go to that pre-compiled file.
Fixes angular/vscode-ng-language-service#1263
PR Close#41538
The language service uses an elements attributes to determine if it
matches a directive in the component scope. We do this by accumulating
all attribute bindings and matching against the selectors for the
available directives. The compiler itself does a similar thing. In
addition, the compiler does not use the value of `BoundAttribute`s to
match directives (cdf1ea1951/packages/compiler/src/render3/view/util.ts (L174-L206)). This commit changes the language
service to also ignore bound attribute values for directive matching.
Fixes https://github.com/angular/vscode-ng-language-service/issues/1278
PR Close#41597
This adds string literals, number literals, `true`, `false`, `null` and
`undefined` to autocomplete results in templates.
For example, when completing an input of union type.
Component: `@Input('input') input!: 'a'|'b'|null;`
Template: `[input]="|"`
Provide `'a'`, `'b'`, and `null` as autocompletion entries.
Previously we did not include literal types because we only included
results from the component context (`ctx.`) and the template scope.
PR Close#41456
This commit implements signature help in the Language Service, on top of
TypeScript's implementation within the TCB.
A separate PR adds support for translation of signature help data from TS'
API to the LSP in the Language Service extension.
PR Close#41581
This commit changes `getTemplateAtTarget` to be able to identify when a
cursor position is specifically within the argument span of a `MethodCall`
or `SafeMethodCall` with no arguments. If the call had arguments, one of the
argument expressions would be returned instead, but in a call with no
arguments the tightest node _is_ the `MethodCall`. Adding the additional
argument context will allow for functionality that relies on tracking
argument positions, like `getSignatureHelpItems`.
PR Close#41581
In environments such as the Language Service where inline type-checking code
is not supported, the compiler would previously produce a diagnostic when a
template would require inlining to check. This happened whenever its
component class had generic parameters with bounds that could not be safely
reproduced in an external TCB. However, this created a bad user experience
for the Language Service, as its features would then not function with such
templates.
Instead, this commit changes the compiler to use the same strategy for
inline TCBs as it does for inline type constructors - falling back to `any`
for generic types when inlining isn't available. This allows the LS to
support such templates with slightly weaker type-checking semantics, which
a test verifies. There is still a case where components that aren't
exported require an inline TCB, and the compiler will still generate a
diagnostic if so.
Fixes#41395
PR Close#41513
With the work done in #41291, the compiler always tracks the last known
program, so there's no need to track the program in the compiler factory
anymore.
PR Close#41517
Currently, we throw a FatalDiagnosticError when we fail to load a resource
(`templateUrl` or `styleUrl`) at various stages in the compiler. This prevents
analysis of the component from completing. This will result in in users not being
able to get any information in the component template when there is a missing
`styleUrl`, for example.
This commit simply tracks the diagnostic, marks the component as poisoned, and
continues merrily along. Environments configured to use poisoned data
(like the language service) will then be able to use other information from the analysis.
Fixes https://github.com/angular/vscode-ng-language-service/issues/1241
PR Close#41403
When possible, the @angular/language-service should only provide
information related to Angular. When there is an embedded language, like
inline templates, editor extensions should have the ability to create
virtual documents and forward the requests to the relevant providers for
that language type (see https://github.com/angular/vscode-ng-language-service/pull/1212).
This commit removes all dom schema completions in both inline and
external templates and provides only the Angular syntax for property completions
on elements.
PR Close#41278
Adds perf tracing for the public methods in LanguageService. If the log level is verbose or higher,
trace performance results to the tsServer logger. This logger is implemented on the extension side
in angular/vscode-ng-language-service.
PR Close#41319
The Ivy Language Service uses the compiler's template type-checking engine,
which honors the configuration in the user's tsconfig.json. We recommend
that users upgrade to `strictTemplates` mode in their projects to take
advantage of the best possible type inference, and thus to have the best
experience in Language Service.
If a project is not using `strictTemplates`, then the compiler will not
leverage certain type inference options it has. One case where this is very
noticeable is the inference of let- variables for structural directives that
provide a template context guard (such as NgFor). Without `strictTemplates`,
these guards will not be applied and such variables will be inferred as
'any', degrading the user experience within Language Service.
This is working as designed, since the Language Service _should_ reflect
types exactly as the compiler sees them. However, the View Engine Language
Service used its own type system that _would_ infer these types even when
the compiler did not. As a result, it's confusing to some users why the
Ivy Language Service has "worse" type inference.
To address this confusion, this commit implements a suggestion diagnostic
which is shown in the Language Service for variables which could have been
narrowed via a context guard, but the type checking configuration didn't
allow it. This should make the reason why variables receive the 'any' type
as well as the action needed to improve the typings much more obvious,
improving the Language Service experience.
Fixes angular/vscode-ng-language-service#1155
Closes#41042
PR Close#41072
This commit fixes the behavior when creating a type constructor for a directive when the following
conditions are met.
1. The directive has bound generic parameters.
2. Inlining is not available. (This happens for language service compiles).
Previously, we would throw an error saying 'Inlining is not supported in this environment.' The
compiler would stop type checking, and the developer could lose out on getting errors after the
compiler gives up.
This commit adds a useInlineTypeConstructors to the type check config. When set to false, we use
`any` type for bound generic parameters to avoid crashing. When set to true, we inline the type
constructor when inlining is required.
Addresses #40963
PR Close#41043
We currently provide completions for DOM elements in the schema as well
as attributes when we are in the context of an external template.
However, these completions are already provided by other extensions for
HTML contexts (like Emmet). To avoid duplication of results, this commit
updates the language service to exclude DOM completions for external
templates. They are still provided for inline templates because those
are not handled by the HTML language extensions.
PR Close#41078
The compiler considers template diagnostics to "belong" to the source file
of the component using the template. This means that when diagnostics for
a source file are reported, it returns diagnostics of TS structures in the
actual source file, diagnostics for any inline templates, and diagnostics of
any external templates.
The Language Service uses a different model, and wants to show template
diagnostics in the actual .html file. Thus, it's not necessary (and in fact
incorrect) to include such diagnostics for the actual .ts file as well.
Doing this currently causes a bug where external diagnostics appear in the
TS file with "random" source spans.
This commit changes the Language Service to filter the set of diagnostics
returned by the compiler and only include those diagnostics with spans
actually within the .ts file itself.
Fixes#41032
PR Close#41070
The current logic in the compiler is to bail when there are errors when
parsing a template into an HTML AST or when there are errors in the i18n
metadata. As a result, a template with these types of parse errors
_will not have any information for the language service_. This is because we
never attempt to conver the HTML AST to a template AST in these
scenarios, so there are no template AST nodes for the language service
to look at for information. In addition, this also means that the errors
are never displayed in the template to the user because there are no
nodes to map the error to.
This commit adds an option to the template parser to temporarily ignore
the html parse and i18n meta errors and always perform the template AST
conversion. At the end, the i18n and HTML parse errors are appended to
the returned errors list. While this seems risky, it at least provides
us with more information than we had before (which was 0) and it's only
done in the context of the language service, when the compiler is
configured to use poisoned data (HTML parse and i18n meta errors can be
interpreted as a "poisoned" template).
fixes angular/vscode-ng-language-service#1140
PR Close#41068
An opening tag `<` without any characters after it is interperted as a
text node (just a "less than" character) rather than the start of an
element in the template AST. This commit adjusts the autocomplete engine
to provide element autocompletions when the nearest character to the
left of the cursor is `<`.
Part of the fix for angular/vscode-ng-language-service#1140
PR Close#41068
This commit adds a new configuration option, `forceStrictTemplates` to the
language service plugin to allow users to force enable `strictTemplates`.
This is needed so that the Angular extension can be used inside Google without
changing the underlying compiler options in the `ng_module` build rule.
PR Close#41062
VSCode only de-duplicates references results for "go to references" requests
but does not de-duplicate them for "find all references" requests. The
result is that users see duplicate references for results in TypeScript
files - one from the built-in TS extension and one from us.
While this is an issue in VSCode (see https://github.com/microsoft/vscode/issues/117095)
this commit provides a quick workaround on our end until it can be addressed there.
This commit should be reverted when microsoft/vscode/issues/117095 is resolved.
fixes https://github.com/angular/vscode-ng-language-service/issues/1124
PR Close#41041
Now the language service always uses the name of the JavaScript property on the
component or directive instance for this input or output. This PR will use the right
binding property name.
PR Close#41005
This commit updates compiler_spec.ts in the Ivy LS suite to utilize the new
testing environment which was introduced in the previous commit. Eventually
all specs should be converted, but converting one right now helps ensure
that the new testing env is working properly and able to support real tests.
PR Close#40966
This commit updates compiler_spec.ts in the Ivy LS suite to utilize the new
testing environment which was introduced in the previous commit. Eventually
all specs should be converted, but converting one right now helps ensure
that the new testing env is working properly and able to support real tests.
PR Close#40679
The Ivy Language Service codebase testing suite contains a few testing
utilities which allow for assertions of Language Service operations against
an in-memory project. However, this existing utility lacks the flexibility
to test more complex scenarios, such as those involving multiple TS projects
with dependencies between them.
This commit introduces a new 'testing' package for the Ivy LS which attempts
to more faithfully represent the possible states of an IDE, and allows for
testing of more advanced scenarios. The new utility borrows from the prior
version and is geared towards more ergonomic testing. Only basic
functionality is present in this initial implementation, but this will grow
over time.
PR Close#40679
The `TemplateTypeChecker.overrideComponentTemplate` operation was originally
conceived as a "fast path" for the Language Service to react to a template
change without needing to go through a full incremental compilation step. It
served this purpose until the previous commit, which switches the LS to use
the new resource-only incremental change operation provided by `NgCompiler`.
`overrideComponentTemplate` is now no longer utilized, and is known to have
several hard-to-overcome issues that prevent it from being useful in any
other situations. As such, this commit removes it entirely.
PR Close#40585
This commit changes the Language Service's "compiler factory" mechanism to
leverage the new resource-only update path for `NgCompiler`. When an
incoming change only affects a resource file like a component template or
stylesheet, going through the new API allows the Language Service to avoid
unnecessary incremental steps of the `NgCompiler` and return answers more
efficiently.
PR Close#40585
If the template parse option `leadingTriviaChars` is configured to
consider whitespace as trivia, any trailing whitespace of an element
would be considered as leading trivia of the subsequent element, such
that its `start` span would start _after_ the whitespace. This means
that the start span cannot be used to mark the end of the current
element, as its trailing whitespace would then be included in its span.
Instead, the full start of the subsequent element should be used.
To harden the tests that for the Ivy parser, the test utility `parseR3`
has been adjusted to use the same configuration for `leadingTriviaChars`
as would be the case in its production counterpart `parseTemplate`. This
uncovered another bug in offset handling of the interpolation parser,
where the absolute offset was computed from the start source span
(which excludes leading trivia) whereas the interpolation expression
would include the leading trivia. As such, the absolute offset now also
uses the full start span.
Fixes#39148
PR Close#40513
The Language Service uses the source span of AST nodes to recognize which
node a user has selected, given their cursor position in a template. This is
used to trigger autocompletion.
The previous source span of BindingPipe nodes created a problem when:
1) the pipe binding had no identifier (incomplete or in-progress expression)
2) the user typed trailing whitespace after the pipe character ('|')
For example, the expression `{{foo | }}`. If the cursor preceded the '}' in
that expression, the Language Service was unable to detect that the user was
autocompleting the BindingPipe expression, since the span of the BindingPipe
ended after the '|'.
This commit changes the expression parser to expand the span of BindingPipe
expressions with a missing identifier, to include any trailing whitespace.
This allows the Language Service to correctly recognize this case as
targeting the BindingPipe and complete it successfully. The `nameSpan` of
the BindingPipe is also moved to be right-aligned with the end of any
whitespace present in the pipe binding expression.
This change allows for the disabled test in the Language Service for pipe
completion in this case to be re-enabled.
PR Close#40346
This PR adds a way for the language server to retrieve compiler options
diagnostics via `languageService.getCompilerOptionsDiagnostics()`.
This will be used by the language server to show a prompt in the editor if
users don't have `strict` or `fullTemplateTypeCheck` turned on.
Ref https://github.com/angular/vscode-ng-language-service/issues/1053
PR Close#40423
This patch adds an API to retrieve the template typecheck block for a
template (if any) at a file location, and a selection of the TS node
in the TCB corresponding to the template node at which the request for
a TCB was made (if any).
Probably not something we want to land soon, but a useful debugging tool
for folks working with TCBs.
PR Close#39974
Rather than mutating the span on the template when renaming literal strings,
this commit updates the logic to mutate the `TextSpan` equivalent that
is used by the Language Service.
PR Close#40484
The initial implementation assumed that the consuming editors would
de-duplicate rename locations. In fact, vscode treats overlapping rename
locations as distinct and errors when trying to preview the renames.
This commit updates the language service to de-duplicate exact file+span
matches before returning rename and reference locations.
While vscode _does_ de-duplicate reference results, it still makes sense
to de-duplicate them on our side when possible to make tests more
understandable. If a template has 3 instances of a variable, it makes
sense to get get 3 reference results rather than 4+ with some duplicates.
PR Close#40454
The current "go to definition" is broken for template variables and
references when a template is overridden. This is because we get the
file url from the source span, which uses the overridden name
'override.html'. Instead, we can retrieve the template file from the
compiler in the same manner that is done for references.
Another way to fix this would have been to use the real template file path when
overriding a template, but this was the more straightforward fix since
the strategy was already used in find references and rename locations.
fixes https://github.com/angular/vscode-ng-language-service/issues/1054
PR Close#40455
The `getRenameInfo` action is used by consumers to
1. Determine if a location is a candidate for renames
2. Determine what text to use as the starting point for the rename
PR Close#40439
Andrew Scott
Zach Arend
Joey Perrott
Alex Rickabaugh
Keen Yee Liau
Kristiyan Kostadinov
ivanwonder
JoostK
ayazhafiz