Commit Graph

470 Commits

Author SHA1 Message Date
Keen Yee Liau 0264f76e94 fix(language-service): LSParseConfigHost.resolve should not concat abs paths (#40242)
`ts.server.ServerHost.resolvePath()` is different from Angular's
`FileSystem.resolve()` because the signature of the former is

```ts
resolvePath(path: string): string;	// ts.server.ServerHost
```

whereas the signature of the latter is
```ts
resolve(...paths: string[]): AbsoluteFsPath; // FileSystem on compiler-cli
```

The current implementation calls `path.join()` to concatenate all the input
paths and pass the result to `ts.server.ServerHost.resolvePath()`, but doing
so results in filenames like
```
/foo/bar/baz/foo/bar/baz/tsconfig.json
```
if both input paths are absolute.

`ts.server.ServerHost` should not be used to implement the
`resolve()` method expected by Angular's `FileSystem`.
We should use Node's `path.resolve()` instead, which will correctly collapse
the absolute paths.

Fix https://github.com/angular/vscode-ng-language-service/issues/1035

PR Close #40242
2021-01-06 10:54:40 -08:00
Keen Yee Liau a62416c6e4 fix(language-service): include compilerOptions.rootDir in rootDirs (#40243)
When resolving references, the Ivy compiler has a few strategies it could use.

For relative path, one of strategies is [`RelativePathStrategy`](
https://github.com/angular/angular/blob/master/packages/compiler-cli/src/
ngtsc/imports/README.md#relativepathstrategy). This strategy
relies on `compilerOptions.rootDir` and `compilerOptions.rootDirs` to perform
the resolution, but language service only passes `rootDirs` to the compiler,
and not `rootDir`.

In reality, `rootDir` is very different from `rootDirs` even though they
sound the same.
According to the official [TS documentation][1],
> `rootDir` specifies the root directory of input files. Only use to control
> the output directory structure with --outDir.

> `rootDirs` is a list of root folders whose combined content represent the
> structure of the project at runtime. See [Module Resolution documentation](
> https://www.typescriptlang.org/docs/handbook/
> module-resolution.html#virtual-directories-with-rootdirs)
> for more details.

For now, we keep the behavior between compiler and language service consistent,
but we will revisit the notion of `rootDir` and how it is used later.

Fix angular/vscode-ng-language-service#1039

[1]: https://www.typescriptlang.org/docs/handbook/compiler-options.html

PR Close #40243
2021-01-06 10:54:11 -08:00
Andrew Scott d466db8285 fix(language-service): Do not include $event parameter in reference results (#40158)
Given the template
`<div (click)="doSomething($event)"></div>`

If you request references for the `$event`, the results include both `$event` and `(click)="doSomething($event)"`.

This happens because in the TCB, `$event` is passed to the `subscribe`/`addEventListener`
function as an argument. So when we ask typescript to give us the references, we
get the result from the usage in the subscribe body as well as the one passed in as an argument.

This commit adds an identifier to the `$event` parameter in the TCB so
that the result returned from `getReferencesAtPosition` can be
identified and filtered out.

fixes #40157

PR Close #40158
2021-01-05 10:07:20 -08:00
Andrew Scott 12cb39c1a4 fix(language-service): shorthand syntax with variables (#40239)
This commit fixes an issue in the ivy native language service
that caused the logic that finds a target node given a template
position to throw away the results. This happened because the
source span of a variable node in the shorthand structural
directive syntax (i.e. `*ngIf=`) included the entire binding.

The result was that we would add the variable node to the path and then
later detect that the cursor was outside the key and value spans and
throw away the whole result. In general, we do this because we do not
want to show information when the cursor is between a key/value
(`inputA=¦"123"`). However, when using the shorthand syntax, we run into
the situation where we can match an `AttributeBinding` as well as the
vaariable in `*ngIf="som¦eValue as myLocalVar"`. This commit updates the
visitor to retain enough information in the visit path to throw away
invalid targets but keep valid ones if there were multiple results on a
`t.Element` or `t.Template`.

PR Close #40239
2020-12-22 14:50:22 -08:00
Zach Arend db97453ca0 refactor(compiler-cli): move template parse errors to TemplateData (#40026)
Durring analysis we find template parse errors. This commit changes
where the type checking context stores the parse errors. Previously, we
stored them on the AnalysisOutput this commit changes the errors to be
stored on the TemplateData (which is a property on the shim). That way,
the template parse errors can be grouped by template.

Previously, if a template had a parse error, we poisoned the module and
would not procede to find typecheck errors. This change does not poison
modules whose template have typecheck errors, so that ngtsc can emit
typecheck errors for templates with parse errors.

Additionally, all template diagnostics are produced in the same place.
This allows requesting just the template template diagnostics or just
other types of errors.

PR Close #40026
2020-12-15 13:30:52 -08:00
Alex Rickabaugh 2a7443117b feat(language-service): completions for structural directives (#40032)
This comit adds support for autocompletion of attributes that create
structural directives. Such completions differ from those of normal
attributes, as the structural directive syntax creates a synthetic
<ng-template> node which has different attributes from the main element.

PR Close #40032
2020-12-14 12:08:41 -08:00
Alex Rickabaugh cbb6eae4a9 feat(language-service): autocomplete pipe binding expressions (#40032)
This commit adds autocompletion for pipe expressions, built on existing APIs
for checking which pipes are in scope.

PR Close #40032
2020-12-14 12:08:41 -08:00
Alex Rickabaugh 66378ed0ef feat(language-service): complete attributes on elements (#40032)
This commit adds attribute completion to the Language Service. It completes
from 3 sources:

1. inputs/outputs of directives currently present on the element
2. inputs/outputs/attributes of directives in scope for the element, that
   would become present if the input/output/attribute was added
3. DOM properties and attributes

We distinguish between completion of a property binding (`[foo|]`) and a
completion in an attribute context (`foo|`). For the latter, bindings to
the attribute are offered, as well as a property binding which adds the
square bracket notation.

To determine hypothetical matches (directives which would become present if
a binding is added), directives in scope are scanned and matched against a
hypothetical version of the element which has the attribute.

PR Close #40032
2020-12-14 12:08:41 -08:00
Alex Rickabaugh e42250f139 feat(language-service): autocompletion of element tags (#40032)
This commit expands the autocompletion capabilities of the language service
to include element tag names. It presents both DOM elements from the Angular
DOM schema as well as any components (or directives with element selectors)
that are in scope within the template as options for completion.

PR Close #40032
2020-12-14 12:08:40 -08:00
Alex Rickabaugh ccaf48de8f refactor(language-service): add context to template target system (#40032)
This commit extends the template targeting system, which determines the node
being referenced given a template position, to return additional context if
needed about the particular aspect of the node to which the position refers.
For example, a position pointing to an element node may be pointing either
to its tag name or to somewhere in the node body. This is the difference
between `<div|>` and `<div foo | bar>`.

PR Close #40032
2020-12-14 12:08:40 -08:00
Zach Arend 19d43af627 fix(dev-infra): add vim .swp files to gitignore (#40094)
The vim editor produces temporarily files that can end in both .swo and
.swp. This commits add .swp to the .gitignore so we don't accidentaly
commit temporary files.

PR Close #40094
2020-12-14 11:39:41 -08:00
Alex Rickabaugh 028e4f7f6d fix(language-service): force compileNonExportedClasses: false in LS (#40092)
Projects opened in the LS are often larger in scope than the compilation
units seen by the compiler when actually building. For example, in the LS
it's not uncommon for the project to include both application as well as
test files. This can create issues when the combination of files results
in errors that are not otherwise present - for example, if test files
have inline NgModules that re-declare components (a common Angular pattern).
Such code is valid when compiling the app only (test files are excluded, so
only one declaration is seen by the compiler) or when compiling tests only
(since tests run in JIT mode and are not seen by the AOT compiler), but when
both sets of files are mixed into a single compilation unit, the compiler
sees the double declaration as an error.

This commit attempts to mitigate the problem by forcing the compiler flag
`compileNonExportedClasses` to `false` in a LS context. When tests contain
duplicate declarations, often such declarations are inline in specs and not
exported from the top level, so this flag can be used to greatly improve the
IDE experience.

PR Close #40092
2020-12-14 10:09:21 -08:00
Andrew Scott 2b74a05a65 refactor(compiler-cli): Enable pipe information when checkTypeOfPipes=false (#39555)
When `checkTypeOfPipes` is set to `false`, the configuration is meant to
ignore the signature of the pipe's `transform` method for diagnostics.
However, we still should produce some information about the pipe for the
`TemplateTypeChecker`. This change refactors the returned symbol for
pipes so that it also includes information about the pipe's class
instance as it appears in the TCB.

PR Close #39555
2020-12-11 16:19:15 -08:00
Andrew Scott 6e4e68cb30 refactor(compiler-cli): Add flag to TCB for non-diagnostic requests (#40071)
The TCB utility functions used to find nodes in the TCB are currently
configured to ignore results when an ignore marker is found. However,
these ignore markers are only meant to affect diagnostics requests. The
Language Service may have a need to find nodes with diagnostic ignore
markers. The most common example of this would be finding references for
generic directives. The reference appears to the generic directive's
class appears on the type ctor in the TCB, which is ignored for
diagnostic purposes.
These functions should only skip results when the request is in the
context of a larger request for _diagnostics_. In all other cases, we
should get matches, even if a diagnostic ignore marker is encountered.

PR Close #40071
2020-12-11 13:56:35 -08:00
Keen Yee Liau 2a386415ce build(language-service): install @angular/language-service in root node_modules (#40058)
https://github.com/angular/vscode-ng-language-service/pull/994 changed the
structure of the vscode-ng-language-service repository to be a monorepo,
so @angular/language-service should be installed in root node_modules.

PR Close #40058
2020-12-10 13:48:04 -08:00
Andrew Scott 973f797ad5 feat(language-service): enable get references for directive and component from template (#40054)
This commit adds the ability to find references for a directive or component
from within a component template. That is, you can find component references
from the element tag `<my-c|omp></my-comp>` (where `|` is the cursor position)
as well as find references for directives that match a given attribute
`<div d|ir></div>`.

PR Close #40054
2020-12-10 13:45:40 -08:00
Andrew Scott 1bf1b685d6 fix(language-service): Prevent matching nodes after finding a keySpan (#40047)
If we've already identified that we are within a `keySpan` of a node, we
exit the visitor logic early. It can be the case that we have two nodes
which technically match a given location when the end span of one node
touches the start of the keySpan for the candidate node. Because
our `isWithin` logic is inclusive on both ends, we can match both nodes.
This change exits the visitor logic once we've identified a node where
the position is within its `keySpan`.

PR Close #40047
2020-12-10 13:44:18 -08:00
Andrew Scott 371a2c82ea refactor(language-service): adjust hybrid visitor to not throw away valid results (#40047)
The visitor has a check in it with the goal of preventing the structural directive
parent elements from matching when we have already found the candidate we want.
However, this code did not check to ensure that it was looking at the correct
type of node for this case and was evaluating this logic in places it shouldn't.
This special check can be more easily done by simply not traversing the
template children if we've already found a candidate on the template
node itself.

PR Close #40047
2020-12-10 13:44:18 -08:00
Alex Rickabaugh 93a83266f9 feat(language-service): autocompletion within expression contexts (#39727)
This commit adds support to the Language Service for autocompletion within
expression contexts. Specifically, this is auto completion of property reads
and method calls, both in normal and safe-navigational forms.

PR Close #39727
2020-12-10 11:09:53 -08:00
Andrew Scott 269a775287 refactor(compiler-cli): produce binding access when checkTypeOfOutputEvents is false (#39515)
When `checkTypeOfOutputEvents` is `false`, we still need to produce the access
to the `EventEmitter` so the Language Service can still get the
type information about the field. That is, in a template `<div
(output)="handle($event)"`, we still want to be able to grab information
when the cursor is inside the "output" parens. The flag is intended only
to affect whether the compiler produces diagnostics for the inferred
type of the `$event`.

PR Close #39515
2020-12-10 11:04:46 -08:00
Andrew Scott 2f8a42036a refactor(compiler-cli): Return addEventListener symbol for native output bindings (#39312)
Rather than returning `null`, we can provide some useful information to the Language Service
by returning a symbol for the `addEventListener` function call when the consumer
of a binding as an element.

PR Close #39312
2020-12-08 16:18:24 -08:00
Andrew Scott a694838c41 refactor(compiler-cli): TemplateTypeChecker with checkTypeOfAttributes=false should still work (#39537)
When the compiler option `checkTypeOfAttributes` is `false`, we should
still be able to produce type information from the
`TemplateTypeChecker`. The current behavior ignores all attributes that
map to directive inputs. This commit includes those attribute bindings
in the TCB but adds the "ignore for diagnostics" marker so they do not
produce errors. This way, consumers of the TTC (the Language Service)
can still get valid information about these attributes even when the
user has configured the compiler to not produce diagnostics/errors for them.

PR Close #39537
2020-12-08 09:14:27 -08:00
Alex Rickabaugh 28a0bcb424 feat(language-service): implement autocompletion for global properties (Ivy) (#39250)
This commit adds support in the Ivy Language Service for autocompletion in a
global context - e.g. a {{foo|}} completion.

Support is added both for the primary function `getCompletionsAtPosition` as
well as the detail functions `getCompletionEntryDetails` and
`getCompletionEntrySymbol`. These latter operations are not used yet as an
upstream change to the extension is required to advertise and support this
capability.

PR Close #39250
2020-12-04 10:19:45 -08:00
Zach Arend de8f0fe5ee test(language-service): convert ivy diagnostics tests from legacy (#39957)
This commit updates the tests for the diagnostics in the ivy language
service to use the new in-memory test environment.

PR Close #39957
2020-12-04 10:16:43 -08:00
ayazhafiz 3b700985f0 fix(language-service): do not treat file URIs as general URLs (#39917)
In the past, the legacy (VE-based) language service would use a
`UrlResolver` instance to resolve file paths, primarily for compiler
resources like external templates. The problem with this is that the
UrlResolver is designed to resolve URLs in general, and so for a path
like `/a/b/#c`, `#c` is treated as hash/fragment rather than as part
of the path, which can lead to unexpected path resolution (f.x.,
`resolve('a/b/#c/d.ts', './d.html')` would produce `'a/b/d.html'` rather
than the expected `'a/b/#c/d.html'`).

This commit resolves the issue by using Node's `path` module to resolve
file paths directly, which aligns more with how resources are resolved
in the Ivy compiler.

The testing story here is not great, and the API for validating a file
path could be a little bit prettier/robust. However, since the VE-based
language service is going into more of a "maintenance mode" now that
there is a clear path for the Ivy-based LS moving forward, I think it is
okay not to spend too much time here.

Closes https://github.com/angular/vscode-ng-language-service/issues/892
Closes https://github.com/angular/vscode-ng-language-service/issues/1001

PR Close #39917
2020-12-03 13:45:30 -08:00
Andrew Scott dd18cfd983 refactor(language-service): create findRenameLocations stubs (#39919)
Create stubs for `findRenameLocations` for both VE and Ivy Language Service
implementations. This will prevent failed requests when it is implemented on the vscode plugin side.

PR Close #39919
2020-12-03 13:44:49 -08:00
Alex Rickabaugh c7c5b2fc1e fix(compiler-cli): correct incremental behavior even with broken imports (#39923)
When the compiler is invoked via ngc or the Angular CLI, its APIs are used
under the assumption that Angular analysis/diagnostics are only requested if
the program has no TypeScript-level errors. A result of this assumption is
that the incremental engine has not needed to resolve changes via its
dependency graph when the program contained broken imports, since broken
imports are a TypeScript error.

The Angular Language Service for Ivy is using the compiler as a backend, and
exercising its incremental compilation APIs without enforcing this
assumption. As a result, the Language Service has run into issues where
broken imports cause incremental compilation to fail and produce incorrect
results.

This commit introduces a mechanism within the compiler to keep track of
files for which dependency analysis has failed, and to always treat such
files as potentially affected by future incremental steps. This is tested
via the Language Service infrastructure to ensure that the compiler is doing
the right thing in the case of invalid imports.

PR Close #39923
2020-12-03 13:42:13 -08:00
Alex Rickabaugh 0823622202 fix(compiler-cli): track poisoned scopes with a flag (#39923)
To avoid overwhelming a user with secondary diagnostics that derive from a
"root cause" error, the compiler has the notion of a "poisoned" NgModule.
An NgModule becomes poisoned when its declaration contains semantic errors:
declarations which are not components or pipes, imports which are not other
NgModules, etc. An NgModule also becomes poisoned if it imports or exports
another poisoned NgModule.

Previously, the compiler tracked this poisoned status as an alternate state
for each scope. Either a correct scope could be produced, or the entire
scope would be set to a sentinel error value. This meant that the compiler
would not track any information about a scope that was determined to be in
error.

This method presents several issues:

1. The compiler is unable to support the language service and return results
when a component or its module scope is poisoned.

This is fine for compilation, since diagnostics will be produced showing the
error(s), but the language service needs to still work for incorrect code.

2. `getComponentScopes()` does not return components with a poisoned scope,
which interferes with resource tracking of incremental builds.

If the component isn't included in that list, then the NgModule for it will
not have its dependencies properly tracked, and this can cause future
incremental build steps to produce incorrect results.

This commit changes the tracking of poisoned module scopes to use a flag on
the scope itself, rather than a sentinel value that replaces the scope. This
means that the scope itself will still be tracked, even if it contains
semantic errors. A test is added to the language service which verifies that
poisoned scopes can still be used in template type-checking.

PR Close #39923
2020-12-03 13:42:13 -08:00
Keen Yee Liau 2b84882ab0 fix(language-service): do not return external template that does not exist (#39898)
There is a bug in tsserver that causes it to crash when it tries to create
script info for an external template that does not exist.

I've submitted an upstream PR
https://github.com/microsoft/TypeScript/pull/41737 to fix this, but before
the commit lands in the stable release, we'll have to workaround the issue
in language service.

Close https://github.com/angular/vscode-ng-language-service/issues/1001

PR Close #39898
2020-12-03 07:15:17 -08:00
Andrew Scott 75fc89384d refactor(compiler-cli): expose TTC method to determine if file is tracked shim (#39768)
The Language Service "find references" currently uses the
`ngtypecheck.ts` suffix to determine if a file is a shim file. Instead,
a better API would be to expose a method in the template type checker
that does this verification so that the LS does not have to "know" about
the typecheck suffix. This also fixes an issue (albeit unlikely) whereby a file
in the user's program that _actually_ is named with the `ngtypecheck.ts`
suffix would have been interpreted as a shim file.

PR Close #39768
2020-12-02 12:54:22 -08:00
Andrew Scott 06a782a2e3 feat(language-service): Add "find references" capability to Ivy integrated LS (#39768)
This commit adds "find references" functionality to the Ivy integrated
language service. The basic approach is as follows:

1. Generate shims for all files to ensure we find references in shims
throughout the entire program
2. Determine if the position for the reference request is within a
template.
  * Yes, it is in a template: Find which node in the template AST the
  position refers to. Then find the position in the shim file for that
  template node. Pass the shim file and position in the shim file along
  to step 3.
  * No, the request for references was made outside a template: Forward
  the file and position to step 3.
3. (`getReferencesAtTypescriptPosition`): Call the native TypeScript LS
`getReferencesAtPosition`. For each reference that is in a shim file, map those
back to a template location, otherwise return it as-is.

PR Close #39768
2020-12-02 12:54:21 -08:00
Andrew Scott 8758006acc refactor(language-service): create getReferencesAtPosition stubs (#39829)
Create stubs for getTypeDefinitionAtPosition for both VE and Ivy Language Service
implementations. This will prevent failed requests when it is implemented on the vscode plugin side.

PR Close #39829
2020-11-24 14:19:48 -08:00
Keen Yee Liau 9aaa86967d build(language-service): include sources for Ivy LS (#39748)
We need to expose the declaration files for Ivy sources so that they can
be consumed by the Angular language server (`@angular/language-server`).

PR Close #39748
2020-11-20 09:23:45 -08:00
Andrew Scott fae2769f44 refactor(compiler-cli): Add additional shim locations to reference and variable symbols (#39715)
Both `ReferenceSymbol` and `VariableSymbol` have two locations of
interest to an external consumer.
1. The location for the initializers of the local TCB variables allow consumers
to query the TypeScript Language Service for information about the initialized type of the variable.
2. The location of the local variable itself (i.e. `_t1`) allows
consumers to query the TypeScript LS for references to that variable
from within the template.

PR Close #39715
2020-11-19 12:15:21 -08:00
ayazhafiz 3a344d4e0e test(language-service): add renamed, deleted test file (#39742)
language_service_adapter_spec was renamed to adapters_spec as part of
d39c4bbe37, but I failed to check in
adapters_spec, thereby just deleting the spec. This reintroduces it.

PR Close #39742
2020-11-18 11:11:14 -08:00
ayazhafiz d39c4bbe37 refactor(language-service): language_service_adapter -> adapters (#39619)
This rename is done because we know have a file system adapter over a
project as well as the compiler adapter.

PR Close #39619
2020-11-17 14:45:09 -08:00
ayazhafiz 64c3135be7 refactor(compiler-cli): provide a host to readConfiguration (#39619)
Currently `readConfiguration` relies on the file system to perform disk
utilities needed to read determine a project configuration file and read
it. This poses a challenge for the language service, which would like to
use `readConfiguration` to watch and read configurations dependent on
extended tsconfigs (#39134). Challenges are at least twofold:

1. To test this, the langauge service would need to provide to the
   compiler a mock file system.
2. The language service uses file system utilities primarily through
   TypeScript's `Project` abstraction. In general this should correspond
   to the underlying file system, but it may differ and it is better to
   go through one channel when possible.

This patch alleviates the concern by directly providing to the compiler
a "ParseConfigurationHost" with read-only "file system"-like utilties.
For the language service, this host is derived from the project owned by
the language service.

For more discussion see
https://docs.google.com/document/d/1TrbT-m7bqyYZICmZYHjnJ7NG9Vzt5Rd967h43Qx8jw0/edit?usp=sharing

PR Close #39619
2020-11-17 14:45:09 -08:00
Alex Rickabaugh b6893d23c5 test(language-service): introduce new virtual testing environment (#39594)
This commit adds new language service testing infrastructure which allows
for in-memory testing. It solves a number of issues with the previous
testing infrastructure that relied on a single integration project across
all of the tests, and also provides for much faster builds by using
the compiler-cli's mock versions of @angular/core and @angular/common.

A new `LanguageServiceTestEnvironment` class (conceptually mirroring the
compiler-cli `NgtscTestEnvironment`) controls setup and execution of tests.
The `FileSystem` abstraction is used to drive a `ts.server.ServerHost`,
which backs the language service infrastructure.

Since many language service tests revolve around the template, the API is
currently optimized to spin up a "skeleton" project and then override its
template for each test.

The existing Quick Info tests (quick_info_spec.ts) were ported to the new
infrastructure for validation. The tests were cleaned up a bit to remove
unnecessary initializations as well as correct legitimate template errors
which did not affect the test outcome, but caused additional validation of
test correctness to fail. They still utilize a shared project with all
fields required for each individual unit test, which is an anti-pattern, but
new tests can now easily be written independently without relying on the
shared project, which was extremely difficult previously. Future cleanup
work might refactor these tests to be more independent.

PR Close #39594
2020-11-17 11:59:56 -08:00
Alex Rickabaugh a7155bc2fa test(language-service): move existing tests to legacy directory (#39594)
In preparation for in-memory testing infrastructure, the existing Ivy
language service tests are moved to a `legacy` directory. These existing
tests rely on a single integration project in `test/project/app`, which
presents a number of challenges:

 * adding extra fields/properties to the integration project for one test
   can cause others to fail/flake.
 * it's especially difficult to test any cases that require introducing
   intentional errors, as those tend to break other tests.
 * tests load files from disk, which is slower.
 * tests rely on the real built versions of @angular/core and
   @angular/common, which makes them both slow to build and require rebuilds
   on every compiler change.
 * tests share a single tsconfig.json, making it extremely difficult to test
   how the language service handles different configuration scenarios (e.g.
   different type-checking flags).

PR Close #39594
2020-11-17 11:59:56 -08:00
Andrew Scott 8a1c98c5e8 refactor(compiler-cli): add keySpan to reference nodes (#39616)
Similar to #39613, #39609, and #38898, we should store the `keySpan` for
Reference nodes so that we can accurately map from a template node to a
span in the original file. This is most notably an issue at the moment
for directive references `#ref="exportAs"`. The current behavior for the
language service when requesting information for the reference
is that it will return a text span that results in
highlighting the entire source when it should only highlight "ref" (test
added for this case as well).

PR Close #39616
2020-11-12 15:12:53 -08:00
Andrew Scott c33326c538 refactor(compiler-cli): add keySpan to parsed events (#39609)
Though we currently have the knowledge of where the `key` for an
event binding appears during parsing, we do not propagate this
information to the output AST. This means that once we produce the
template AST, we have no way of mapping a template position to the key
span alone. The best we can currently do is map back to the
`sourceSpan`. This presents problems downstream, specifically for the
language service, where we cannot provide correct information about a
position in a template because the AST is not granular enough.

This is essentially identical to the change from #38898, but for event
bindings rather than input bindings.

PR Close #39609
2020-11-12 15:09:17 -08:00
Andrew Scott 21651d362d refactor(compiler-cli): add keySpan to text attributes (#39613)
Similar to #39609 and #38898, though we currently have the knowledge of where the key for an
attribute appears during parsing, we do not propagate this
information to the output AST. This means that once we produce the
template AST, we have no way of mapping a template position to the key
span alone. The best we can currently do is map back to the
sourceSpan. This presents problems downstream, specifically for the
language service, where we cannot provide correct information about a
position in a template because the AST is not granular enough.

PR Close #39613
2020-11-12 14:19:00 -08:00
Andrew Scott 3a1d36cce3 refactor(language-service): Use compiler APIs in Ivy to get definitions for external resources (#39476)
Rather than re-reading component metadata that was already interpreted
by the Ivy compiler, the Language Service should instead use the
compiler APIs to get information it needs about the metadata.

PR Close #39476
2020-11-06 09:17:33 -08:00
Alex Rickabaugh eaace44d57 refactor(language-service): refactor `HybridVisitor` and expand its capabilities (#39505)
This commit takes the `HybridVisitor` in the language service and gives it
the ability to return not just a node but the template context in which it
appears. In the future, more context regarding where a node appears in the
template might become necessary (ex: the microsyntax container for binding
nodes), and this refactoring enables that.

In the process, `HybridVisitor` is renamed and the concept of a
`TemplateTarget` interface is introduced to contain the results of this
operation.

PR Close #39505
2020-11-02 10:29:50 -08:00
Alex Rickabaugh 643c96184c refactor(language-service): introduce DisplayParts abstraction for Ivy (#39505)
This commit refactors the QuickInfo abstraction shared between the VE and
Ivy services and used to implement hover tooltips (quick info), which was
extracted from the VE code in commit faa81dc. The new DisplayParts
abstraction is more general and can be used to extract information needed by
various LS functions (e.g. autocompletion).

This commit effectively reverts faa81dc, returning the original code to the
VE implementation as the Ivy code is now diverged.

PR Close #39505
2020-11-02 10:29:50 -08:00
Kristiyan Kostadinov cbc0907bfd fix(compiler): preserve this.$event and this.$any accesses in expressions (#39323)
Currently expressions `$event.foo()` and `this.$event.foo()`, as well as `$any(foo)` and
`this.$any(foo)`, are treated as the same expression by the compiler, because `this` is considered
the same implicit receiver as when the receiver is omitted. This introduces the following issues:

1. Any time something called `$any` is used, it'll be stripped away, leaving only the first parameter.
2. If something called `$event` is used anywhere in a template, it'll be preserved as `$event`,
rather than being rewritten to `ctx.$event`, causing the value to undefined at runtime. This
applies to listener, property and text bindings.

These changes resolve the first issue and part of the second one by preserving anything that
is accessed through `this`, even if it's one of the "special" ones like `$any` or `$event`.
Furthermore, these changes only expose the `$event` global variable inside event listeners,
whereas previously it was available everywhere.

Fixes #30278.

PR Close #39323
2020-10-30 10:49:15 -07:00
ayazhafiz 19b88cef71 fix(compiler): do not throw away render3 AST on errors (#39413)
Currently render3's `parseTemplate` throws away the parsed AST and
returns an empty list of HTML nodes if HTML->R3 translation failed. This
is not preferrable in some contexts like that of a language service,
where we would like a well-formed AST even if it is has errors.

PR Close #39413
2020-10-27 13:37:19 -07:00
Keen Yee Liau 0268b72d2c Revert "test(language-service): Make project service a singleton (#39308)" (#39322)
This reverts commit 1b21350e17.

PR Close #39322
2020-10-19 09:25:19 -07:00
Keen Yee Liau 1b21350e17 test(language-service): Make project service a singleton (#39308)
Constructing a project service is expensive. Making it a singleton could
speed up tests considerably.

On my MacBook Pro, test execution went from 24.4s to 14.5s (~40% improvement).

PR Close #39308
2020-10-16 12:34:16 -07:00
Keen Yee Liau 0c01c4a898 test(language-service): wrap setup() in beforeAll to speed up fit() test (#39305)
Test harness `setup()` is expensive, in the order of ~2.5 seconds.

We could speed up `fit()` tests considerably if `setup()` is wrapped
in `beforeAll()` to avoid running it unnecessarily.

PR Close #39305
2020-10-16 12:33:36 -07:00