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
transpiler: show line numbers that have errors #1
Comments
You can achieve this by using the error reporter in the transformer, ie |
I just tried this with the Karma setup. This fails Traceur compilation and does not even run the tests. The output shows line numbers and errors:
I also improved the way gulp shows the errors (see 7d0a83a). Now it looks like this:
Please re-open if you have any suggestions how to make it better. |
rebuild based on most current angular 2 on npm
This fixes the following type error that is thrown when calling getAllAngularTestability() while running Dartium in checked mode: type 'MappedListIterable' is not a subtype of type 'List<PublicTestability>' of 'publicTestabilities'. #0 GetTestability.addToWindow.<anonymous closure> (package:angular2/src/core/testability/get_testability.dart:92:12) #1 Function._apply (dart:core-patch/function_patch.dart:7) angular#2 Function.apply (dart:core-patch/function_patch.dart:28) angular#3 __invokeFn (package:angular2/src/core/testability/get_testability.dart:26:26) angular#4 _jsFunction.<anonymous closure> (package:angular2/src/core/testability/get_testability.dart:15:12)
These tests validate the ability of the View Engine TestBed to consume summary metadata, a mechanism which allows the TestBed to use AOT-compiled components & directives in tests. It achieves this through two operations which are independently obsolete in Ivy: 1. It injects CompileMetadataResolver, a View Engine specific compiler internal class which extracts global analysis metadata from classes, and uses it to construct summary metadata. This happens in a beforeEach() block which calls createSummaries(). 2. It uses TestBed.initTestEnvironment to pass summary metadata to the TestBed itself. Any such metadata is ignored in Ivy. Operation #1 makes it impossible to run these tests under Ivy, as the CompileMetadataResolver is not available with an Ivy compiler. Ivy itself does not rely on summary data, and the R3TestBed can depend directly on AOT compiled components without it. Thus, the spirit of thes tests is obsolete in an Ivy world. FW-838 #resolve
These tests validate the ability of the View Engine TestBed to consume summary metadata, a mechanism which allows the TestBed to use AOT-compiled components & directives in tests. It achieves this through two operations which are independently obsolete in Ivy: 1. It injects CompileMetadataResolver, a View Engine specific compiler internal class which extracts global analysis metadata from classes, and uses it to construct summary metadata. This happens in a beforeEach() block which calls createSummaries(). 2. It uses TestBed.initTestEnvironment to pass summary metadata to the TestBed itself. Any such metadata is ignored in Ivy. Operation #1 makes it impossible to run these tests under Ivy, as the CompileMetadataResolver is not available with an Ivy compiler. Ivy itself does not rely on summary data, and the R3TestBed can depend directly on AOT compiled components without it. Thus, the spirit of thes tests is obsolete in an Ivy world. FW-838 #resolve
…8027) These tests validate the ability of the View Engine TestBed to consume summary metadata, a mechanism which allows the TestBed to use AOT-compiled components & directives in tests. It achieves this through two operations which are independently obsolete in Ivy: 1. It injects CompileMetadataResolver, a View Engine specific compiler internal class which extracts global analysis metadata from classes, and uses it to construct summary metadata. This happens in a beforeEach() block which calls createSummaries(). 2. It uses TestBed.initTestEnvironment to pass summary metadata to the TestBed itself. Any such metadata is ignored in Ivy. Operation #1 makes it impossible to run these tests under Ivy, as the CompileMetadataResolver is not available with an Ivy compiler. Ivy itself does not rely on summary data, and the R3TestBed can depend directly on AOT compiled components without it. Thus, the spirit of thes tests is obsolete in an Ivy world. FW-838 #resolve PR Close #28027
Prior to this change the postprocess step relied on the order of placeholders combined in one group (e.g. [�#1�|�*1:1�]). The order is not guaranteed in case we have nested templates (since we use BFS to process templates) and some tags are represented using same placeholders. This change performs postprocessing more accurate by keeping track of currently active template and searching for matching placeholder.
) Prior to this change the postprocess step relied on the order of placeholders combined in one group (e.g. [�#1�|�*1:1�]). The order is not guaranteed in case we have nested templates (since we use BFS to process templates) and some tags are represented using same placeholders. This change performs postprocessing more accurate by keeping track of currently active template and searching for matching placeholder. PR Close #28209
…gular#28027) These tests validate the ability of the View Engine TestBed to consume summary metadata, a mechanism which allows the TestBed to use AOT-compiled components & directives in tests. It achieves this through two operations which are independently obsolete in Ivy: 1. It injects CompileMetadataResolver, a View Engine specific compiler internal class which extracts global analysis metadata from classes, and uses it to construct summary metadata. This happens in a beforeEach() block which calls createSummaries(). 2. It uses TestBed.initTestEnvironment to pass summary metadata to the TestBed itself. Any such metadata is ignored in Ivy. Operation angular#1 makes it impossible to run these tests under Ivy, as the CompileMetadataResolver is not available with an Ivy compiler. Ivy itself does not rely on summary data, and the R3TestBed can depend directly on AOT compiled components without it. Thus, the spirit of thes tests is obsolete in an Ivy world. FW-838 #resolve PR Close angular#28027
…ular#28209) Prior to this change the postprocess step relied on the order of placeholders combined in one group (e.g. [�angular#1�|�*1:1�]). The order is not guaranteed in case we have nested templates (since we use BFS to process templates) and some tags are represented using same placeholders. This change performs postprocessing more accurate by keeping track of currently active template and searching for matching placeholder. PR Close angular#28209
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. |
E.g. error from writing
method(String s)
(which should bemethod(s:string)
)The text was updated successfully, but these errors were encountered: