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

transpiler: show line numbers that have errors #1

Closed
tbosch opened this issue Sep 19, 2014 · 3 comments
Closed

transpiler: show line numbers that have errors #1

tbosch opened this issue Sep 19, 2014 · 3 comments

Comments

@tbosch
Copy link
Contributor

tbosch commented Sep 19, 2014

E.g. error from writing method(String s) (which should be method(s:string))

@tbosch tbosch changed the title Build: show line numbers that have errors build: show line numbers that have errors Sep 29, 2014
@tbosch tbosch changed the title build: show line numbers that have errors transpiler: show line numbers that have errors Sep 29, 2014
@mhevery mhevery modified the milestone: October Sep 29, 2014
@vicb
Copy link
Contributor

vicb commented Oct 2, 2014

You can achieve this by using the error reporter in the transformer, ie this.reporter.reportError(location, msg);
location can be retrieved from the parse tree

@vojtajina
Copy link
Contributor

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:

INFO [watcher]: Changed file "/Users/vojta/Code/angular/modules/core/src/compiler/compiler.js".
ERROR [traceur]: /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:11:24: Unexpected token templateLoader
ERROR [traceur]: /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:11:38: Unexpected token )
ERROR [traceur]: /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:20: Unexpected token :
ERROR [traceur]: /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:21: Semi-colon expected
ERROR [traceur]: /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:34: Semi-colon expected
ERROR [traceur]: /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:34: Unexpected token :
ERROR [traceur]: /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:35: Semi-colon expected
ERROR [traceur]: /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:53: Semi-colon expected
ERROR [traceur]: /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:53: Unexpected token )
ERROR [traceur]: /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:54: Semi-colon expected
ERROR [traceur]: /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:54: Unexpected token :
ERROR [traceur]: /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:55: Semi-colon expected
ERROR [traceur]: /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:78: Semi-colon expected
ERROR [traceur]: /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:29:1: Unexpected token End of File
Chrome 40.0.2210 (Mac OS X 10.9.5) ERROR
  TEST RUN WAS CANCELLED because this file contains some errors:
    /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js

I also improved the way gulp shows the errors (see 7d0a83a). Now it looks like this:

Error: gulp-traceur:
  /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:11:24: Unexpected token templateLoader
  /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:11:38: Unexpected token )
  /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:20: Unexpected token :
  /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:21: Semi-colon expected
  /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:34: Semi-colon expected
  /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:34: Unexpected token :
  /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:35: Semi-colon expected
  /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:53: Semi-colon expected
  /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:53: Unexpected token )
  /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:54: Semi-colon expected
  /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:54: Unexpected token :
  /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:55: Semi-colon expected
  /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:23:78: Semi-colon expected
  /Users/vojta/Code/angular/modules/core/src/compiler/compiler.js:29:1: Unexpected token End of File

Please re-open if you have any suggestions how to make it better.

@vojtajina vojtajina removed the ready label Nov 5, 2014
jcoyne pushed a commit to jcoyne/angular that referenced this issue Apr 12, 2015
rebuild based on most current angular 2 on npm
goderbauer referenced this issue in goderbauer/angular Aug 7, 2015
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)
alxhub referenced this issue in alxhub/angular Jan 9, 2019
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
alxhub referenced this issue in alxhub/angular Jan 9, 2019
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
AndrewKushnir pushed a commit that referenced this issue Jan 9, 2019
…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
AndrewKushnir referenced this issue in AndrewKushnir/angular Jan 17, 2019
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.
jasonaden pushed a commit that referenced this issue Jan 25, 2019
)

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
ngfelixl pushed a commit to ngfelixl/angular that referenced this issue Jan 28, 2019
…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
vetom pushed a commit to vetom/angular that referenced this issue Jan 31, 2019
…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
@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 Sep 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants