Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(language-service): provide autocomplete results for incomplete element tags #41068

Closed
wants to merge 2 commits into from

Conversation

atscott
Copy link
Contributor

@atscott atscott commented Mar 3, 2021

(The first commit is included in #41054 and will get removed from this PR upon rebase)

Commit 1:
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

Commit 2:
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 convert 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

@atscott atscott added action: review The PR is still awaiting reviews from at least one requested reviewer area: language-service Issues related to Angular's VS Code language service target: patch This PR is targeted for the next patch release area: compiler Issues related to `ngc`, Angular's template compiler labels Mar 3, 2021
@atscott atscott requested review from kyliau, alxhub and zarend March 3, 2021 16:19
@ngbot ngbot bot modified the milestone: Backlog Mar 3, 2021
@google-cla google-cla bot added the cla: yes label Mar 3, 2021
@atscott atscott changed the title Incomplete template ast fix(language-service): provide autocomplete results for incomplete element tags Mar 3, 2021
@atscott
Copy link
Contributor Author

atscott commented Mar 3, 2021

presubmit

packages/language-service/ivy/completions.ts Outdated Show resolved Hide resolved
packages/language-service/ivy/completions.ts Outdated Show resolved Hide resolved
packages/language-service/ivy/completions.ts Outdated Show resolved Hide resolved
packages/language-service/ivy/completions.ts Outdated Show resolved Hide resolved
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
…sion for LS

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
@atscott atscott added action: merge The PR is ready for merge by the caretaker and removed action: review The PR is still awaiting reviews from at least one requested reviewer labels Mar 3, 2021
@atscott atscott removed the request for review from zarend March 3, 2021 19:34
zarend pushed a commit that referenced this pull request Mar 3, 2021
…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
zarend pushed a commit that referenced this pull request Mar 3, 2021
…sion for LS (#41068)

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
@zarend zarend closed this in 1e3c870 Mar 3, 2021
zarend pushed a commit that referenced this pull request Mar 3, 2021
…sion for LS (#41068)

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
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Apr 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
action: merge The PR is ready for merge by the caretaker area: compiler Issues related to `ngc`, Angular's template compiler area: language-service Issues related to Angular's VS Code language service cla: yes target: patch This PR is targeted for the next patch release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

No more completion for components / HTML tags in Ivy mode
3 participants