fix(compiler): ensure that placeholders have the correct sourceSpan #39717
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
petebacondarwin
force-pushed
the
i18n-more-equiv-text-source-span-woes-issue-39671
branch
from
06d498c
to
73df49d
Compare
petebacondarwin
added
action: review
petebacondarwin
added
the
target: patch
petebacondarwin
force-pushed
the
i18n-more-equiv-text-source-span-woes-issue-39671
branch
from
dab6e08
to
08f5c7e
Compare
AndrewKushnir
approved these changes
Nov 17, 2020
AndrewKushnir
added
the
action: presubmit
AndrewKushnir
removed
the
action: presubmit
|
@petebacondarwin FYI, presubmit is successful for the changes in this PR. Thank you. |
petebacondarwin
added
action: merge
15 tasks
This helper improves the message given when an expectation fails in a source-mapping test.
When the `preserveWhitespaces` is not true, the template parser will process the parsed AST nodes to remove excess whitespace. Since the generated `goog.getMsg()` statements rely upon the AST nodes after this whitespace is removed, the i18n extraction must make a second pass. Previously this resulted in innacurrate source-spans for the i18n text and placeholder nodes that were extracted in the second pass. This commit fixes this by reusing the source-spans from the first pass when extracting the nodes in the second pass. Fixes angular#39671
When parsing for i18n messages, interpolated strings are split into `Text` and `Placeholder` pieces. The method that does this `_visitTextWithInterpolation()` was becoming too complex. This commit refactors that method along with some associated functions that it uses.
petebacondarwin
force-pushed
the
i18n-more-equiv-text-source-span-woes-issue-39671
branch
from
08f5c7e
to
9ee0012
Compare
AndrewKushnir
pushed a commit
that referenced
this pull request
Nov 20, 2020
This helper improves the message given when an expectation fails in a source-mapping test. PR Close #39717
AndrewKushnir
pushed a commit
that referenced
this pull request
Nov 20, 2020
…39717) When the `preserveWhitespaces` is not true, the template parser will process the parsed AST nodes to remove excess whitespace. Since the generated `goog.getMsg()` statements rely upon the AST nodes after this whitespace is removed, the i18n extraction must make a second pass. Previously this resulted in innacurrate source-spans for the i18n text and placeholder nodes that were extracted in the second pass. This commit fixes this by reusing the source-spans from the first pass when extracting the nodes in the second pass. Fixes #39671 PR Close #39717
AndrewKushnir
pushed a commit
that referenced
this pull request
Nov 20, 2020
When parsing for i18n messages, interpolated strings are split into `Text` and `Placeholder` pieces. The method that does this `_visitTextWithInterpolation()` was becoming too complex. This commit refactors that method along with some associated functions that it uses. PR Close #39717
AndrewKushnir
pushed a commit
that referenced
this pull request
Nov 20, 2020
…39717) When the `preserveWhitespaces` is not true, the template parser will process the parsed AST nodes to remove excess whitespace. Since the generated `goog.getMsg()` statements rely upon the AST nodes after this whitespace is removed, the i18n extraction must make a second pass. Previously this resulted in innacurrate source-spans for the i18n text and placeholder nodes that were extracted in the second pass. This commit fixes this by reusing the source-spans from the first pass when extracting the nodes in the second pass. Fixes #39671 PR Close #39717
AndrewKushnir
pushed a commit
that referenced
this pull request
Nov 20, 2020
When parsing for i18n messages, interpolated strings are split into `Text` and `Placeholder` pieces. The method that does this `_visitTextWithInterpolation()` was becoming too complex. This commit refactors that method along with some associated functions that it uses. PR Close #39717
petebacondarwin
deleted the
i18n-more-equiv-text-source-span-woes-issue-39671
branch
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When the
preserveWhitespacesis not true, the template parser willprocess the parsed AST nodes to remove excess whitespace. Since the
generated
goog.getMsg()statements rely upon the AST nodes afterthis whitespace is removed, the i18n extraction must make a second pass.
Previously this resulted in innacurrate source-spans for the i18n text and
placeholder nodes that were extracted in the second pass.
This commit fixes this by reusing the source-spans from the first pass
when extracting the nodes in the second pass.
Fixes #39671