fix(ngcc): handle compilation diagnostics #31996

JoostK · 2019-08-04T17:23:07Z

Previously, any diagnostics reported during the compilation of an
entry-point would not be shown to the user, but either be ignored or
cause a hard crash in case of a FatalDiagnosticError. This is
unfortunate, as such error instances contain information on which code
was responsible for producing the error, whereas only its error message
would not. Therefore, it was quite hard to determine where the error
originates from.

This commit introduces behavior to deal with error diagnostics in a more
graceful way. Such diagnostics will still cause the compilation to fail,
however the error message now contains formatted diagnostics.

Closes #31977
Resolves FW-1374

petebacondarwin

One suggestion to avoid having to make up our own FormatDiagnosticHost.

packages/compiler-cli/ngcc/src/diagnostics.ts

packages/compiler-cli/ngcc/src/main.ts

gkalpak

😍

JoostK · 2019-08-08T20:09:34Z

Blocked on a legit Codefresh failure. Instead of fixing it right away, we'll first make sure the emulated Windows FS mode behaves identical to the native Windows FS mode as to catch such failures earlier in the future.

petebacondarwin · 2019-08-08T20:59:45Z

Good man @JoostK !!

alxhub · 2019-08-09T16:42:52Z

@JoostK sounds good! I'm gonna remove merge-assistance so this doesn't get merged until the codefresh failure is fixed.

JoostK · 2019-08-11T14:04:14Z

Oh no! We don't currently have a Windows CI as Codefresh configuration was recently removed. I deliberately did not rebase my branch hoping that Codefresh would still run on the branch, but that doesn't appear to be the case :-(

@petebacondarwin I did add commit 3fdb4af which should resolve the discrepancy between emulated and native Windows mode. But unfortunately I can't test on native Windows now that Codefresh is gone...

petebacondarwin · 2019-08-11T14:10:10Z

@gkalpak is sometimes able to run things on his Windows setup...

gkalpak · 2019-08-12T09:36:02Z

packages/compiler-cli/src/ngtsc/file_system/testing/src/mock_file_system_native.ts

+    // (see `MockFileSystemWindows`) so that the behavior is identical between native Windows and
+    // emulated Windows mode.
+    if (isWindows) {
+      path = path.replace(/^[\/\\]/i, 'C:/') as T;


Nit: The i flag is redundant (as is escaping / inside [...] 😁).

gkalpak · 2019-08-12T10:22:02Z

As discussed "offline":

I ran yarn test-ivy-aot //packages/compiler-cli/ngcc/test/... //packages/compiler-cli/test/ngtsc and all tests passed (but ngcc/test:integration is skipped due to its no-ivy-aot tag).

Running yarn bazel test //packages/compiler-cli/ngcc/test/... //packages/compiler-cli/test/ngtsc gives the following failure for ngcc/test:integration:

<<FileSystem: Native>> ngcc main() diagnostics should fail with formatted diagnostics when an error diagnostic is produced
  Message:
    Expected function to throw an exception with message 'Failed to compile entry-point fatal-error due to compilation errors:
    node_modules/fatal-error/index.js(5,17): error TS-992001: component is missing a template
    ', but it threw an exception with message 'Failed to compile entry-point fatal-error due to compilation errors:
    node_modules/fatal-error/index.js(5,17): error TS-992001: component is missing a template
    '.

The difference being that the actual error ends with \r\n instead of \n. So, changing this assertion:

.toThrowError(
    'Failed to compile entry-point fatal-error due to compilation errors:\n' +
    'node_modules/fatal-error/index.js(5,17): error TS-992001: component is missing a template\n');

...to something like...

.toThrowError(
    'Failed to compile entry-point fatal-error due to compilation errors:\n' +
    `node_modules/fatal-error/index.js(5,17): error TS-992001: component is missing a template${require('os').EOL}`);

...makes all tests pass.

Interestingly, hard-coding \r\n in the above assertion, also makes all tests pass on Windows, which probably means that the mock-fs is doing something wrong (e.g. not mocking the system's EOL property, so that ts.formatDiagnostics() always uses the native EOL instead of the mocked one).

I am not sure what is the best way to solve this (e.g. normalize newlines in ts.formatDiagnostics() or fix the assertions, etc.). but normalizing newlines to \n on the output of ts.formatDiagnostics() sounds reasonable to me (assuming it does not break something else 😁).

mhevery · 2019-08-29T04:29:45Z

Is this still blocked?

mhevery · 2019-08-29T04:30:25Z

presubmit

gkalpak · 2019-08-29T10:07:36Z

I just rerun the tests on Windows and they passed 👍

The Angular compiler has an emulation system for various kinds of filesystems and runs its testcases for all those filesystems. This allows to verify that the compiler behaves correctly in all of the supported platforms, without needing to run the tests on the actual platforms. Previously, the emulated Windows mode would normalize rooted paths to always include a drive letter, whereas the native mode did not perform this normalization. The consequence of this discrepancy was that running the tests in native Windows was behaving differently compared to how emulated Windows mode behaves, potentially resulting in test failures in native Windows that would succeed for emulated Windows. This commit adds logic to ensure that paths are normalized equally for emulated Windows and native Windows mode, therefore resolving the discrepancy.

Previously, any diagnostics reported during the compilation of an entry-point would not be shown to the user, but either be ignored or cause a hard crash in case of a `FatalDiagnosticError`. This is unfortunate, as such error instances contain information on which code was responsible for producing the error, whereas only its error message would not. Therefore, it was quite hard to determine where the error originates from. This commit introduces behavior to deal with error diagnostics in a more graceful way. Such diagnostics will still cause the compilation to fail, however the error message now contains formatted diagnostics. Closes angular#31977 Resolves FW-1374

JoostK · 2019-08-29T13:08:30Z

merge-assistance: job "legacy-unit-tests-saucelabs" is consistently timing out, unrelated to these changes.

Previously, any diagnostics reported during the compilation of an entry-point would not be shown to the user, but either be ignored or cause a hard crash in case of a `FatalDiagnosticError`. This is unfortunate, as such error instances contain information on which code was responsible for producing the error, whereas only its error message would not. Therefore, it was quite hard to determine where the error originates from. This commit introduces behavior to deal with error diagnostics in a more graceful way. Such diagnostics will still cause the compilation to fail, however the error message now contains formatted diagnostics. Closes #31977 Resolves FW-1374 PR Close #31996

angular#31996) The Angular compiler has an emulation system for various kinds of filesystems and runs its testcases for all those filesystems. This allows to verify that the compiler behaves correctly in all of the supported platforms, without needing to run the tests on the actual platforms. Previously, the emulated Windows mode would normalize rooted paths to always include a drive letter, whereas the native mode did not perform this normalization. The consequence of this discrepancy was that running the tests in native Windows was behaving differently compared to how emulated Windows mode behaves, potentially resulting in test failures in native Windows that would succeed for emulated Windows. This commit adds logic to ensure that paths are normalized equally for emulated Windows and native Windows mode, therefore resolving the discrepancy. PR Close angular#31996

Previously, any diagnostics reported during the compilation of an entry-point would not be shown to the user, but either be ignored or cause a hard crash in case of a `FatalDiagnosticError`. This is unfortunate, as such error instances contain information on which code was responsible for producing the error, whereas only its error message would not. Therefore, it was quite hard to determine where the error originates from. This commit introduces behavior to deal with error diagnostics in a more graceful way. Such diagnostics will still cause the compilation to fail, however the error message now contains formatted diagnostics. Closes angular#31977 Resolves FW-1374 PR Close angular#31996

angular#31996) The Angular compiler has an emulation system for various kinds of filesystems and runs its testcases for all those filesystems. This allows to verify that the compiler behaves correctly in all of the supported platforms, without needing to run the tests on the actual platforms. Previously, the emulated Windows mode would normalize rooted paths to always include a drive letter, whereas the native mode did not perform this normalization. The consequence of this discrepancy was that running the tests in native Windows was behaving differently compared to how emulated Windows mode behaves, potentially resulting in test failures in native Windows that would succeed for emulated Windows. This commit adds logic to ensure that paths are normalized equally for emulated Windows and native Windows mode, therefore resolving the discrepancy. PR Close angular#31996

Previously, any diagnostics reported during the compilation of an entry-point would not be shown to the user, but either be ignored or cause a hard crash in case of a `FatalDiagnosticError`. This is unfortunate, as such error instances contain information on which code was responsible for producing the error, whereas only its error message would not. Therefore, it was quite hard to determine where the error originates from. This commit introduces behavior to deal with error diagnostics in a more graceful way. Such diagnostics will still cause the compilation to fail, however the error message now contains formatted diagnostics. Closes angular#31977 Resolves FW-1374 PR Close angular#31996

angular-automatic-lock-bot · 2019-09-29T16:04:40Z

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.}

JoostK added type: bug/fix action: review The PR is still awaiting reviews from at least one requested reviewer effort1: hours workaround4: none freq1: low severity2: inconvenient target: major This PR is targeted for the next major release risk: low labels Aug 4, 2019

ngbot bot added this to the Backlog milestone Aug 4, 2019

googlebot added the cla: yes label Aug 4, 2019

JoostK force-pushed the ngcc-handle-diagnostics branch from 2ff361d to 00035a1 Compare August 4, 2019 18:19

JoostK marked this pull request as ready for review August 4, 2019 19:05

JoostK requested a review from a team as a code owner August 4, 2019 19:05

petebacondarwin approved these changes Aug 4, 2019

View reviewed changes

packages/compiler-cli/ngcc/src/diagnostics.ts Outdated Show resolved Hide resolved

packages/compiler-cli/ngcc/src/main.ts Outdated Show resolved Hide resolved

petebacondarwin added action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews and removed action: review The PR is still awaiting reviews from at least one requested reviewer labels Aug 4, 2019

JoostK added action: merge The PR is ready for merge by the caretaker and removed action: cleanup The PR is in need of cleanup, either due to needing a rebase or in response to comments from reviews labels Aug 5, 2019

gkalpak reviewed Aug 5, 2019

View reviewed changes

JoostK force-pushed the ngcc-handle-diagnostics branch 2 times, most recently from 8738754 to e8a2878 Compare August 8, 2019 19:01

JoostK added merge: caretaker note Alert the caretaker performing the merge to check the PR for an out of normal action needed or note state: blocked labels Aug 8, 2019

alxhub removed the merge: caretaker note Alert the caretaker performing the merge to check the PR for an out of normal action needed or note label Aug 9, 2019

JoostK force-pushed the ngcc-handle-diagnostics branch from e8a2878 to 3ff6b7b Compare August 11, 2019 13:47

JoostK requested a review from a team as a code owner August 11, 2019 13:47

gkalpak reviewed Aug 12, 2019

View reviewed changes

JoostK force-pushed the ngcc-handle-diagnostics branch from 3ff6b7b to 78fdacc Compare August 18, 2019 18:19

gkalpak approved these changes Aug 29, 2019

View reviewed changes

JoostK added 2 commits August 29, 2019 13:59

JoostK force-pushed the ngcc-handle-diagnostics branch from 78fdacc to 504f500 Compare August 29, 2019 12:02

JoostK changed the title ~~fix(ivy): ngcc - handle compilation diagnostics~~ fix(ngcc): handle compilation diagnostics Aug 29, 2019

JoostK added merge: caretaker note Alert the caretaker performing the merge to check the PR for an out of normal action needed or note and removed state: blocked labels Aug 29, 2019

mhevery closed this in 4161d19 Aug 29, 2019

angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 29, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(ngcc): handle compilation diagnostics #31996

fix(ngcc): handle compilation diagnostics #31996

JoostK commented Aug 4, 2019

petebacondarwin left a comment

gkalpak left a comment

JoostK commented Aug 8, 2019

petebacondarwin commented Aug 8, 2019

alxhub commented Aug 9, 2019

JoostK commented Aug 11, 2019

petebacondarwin commented Aug 11, 2019

gkalpak Aug 12, 2019

gkalpak commented Aug 12, 2019 •

edited

mhevery commented Aug 29, 2019

mhevery commented Aug 29, 2019

gkalpak commented Aug 29, 2019

JoostK commented Aug 29, 2019

angular-automatic-lock-bot bot commented Sep 29, 2019

fix(ngcc): handle compilation diagnostics #31996

fix(ngcc): handle compilation diagnostics #31996

Conversation

JoostK commented Aug 4, 2019

petebacondarwin left a comment

Choose a reason for hiding this comment

gkalpak left a comment

Choose a reason for hiding this comment

JoostK commented Aug 8, 2019

petebacondarwin commented Aug 8, 2019

alxhub commented Aug 9, 2019

JoostK commented Aug 11, 2019

petebacondarwin commented Aug 11, 2019

gkalpak Aug 12, 2019

Choose a reason for hiding this comment

gkalpak commented Aug 12, 2019 • edited

mhevery commented Aug 29, 2019

mhevery commented Aug 29, 2019

gkalpak commented Aug 29, 2019

JoostK commented Aug 29, 2019

angular-automatic-lock-bot bot commented Sep 29, 2019

gkalpak commented Aug 12, 2019 •

edited