[JSC_PARSE_ERROR] Character is not a valid identifier start char

[Scott Chantry]

I am getting the following error when I try compiling using the Java API:

productivity_ui.js:4697: ERROR - [JSC_PARSE_ERROR] Parse error. Character '╕' (U+00B8) is not a valid identifier start char

function polarToCartesian(cX, cY, r, ╬╕) {

The actual character being used is θ which is unicode U+03B8.  Even if I change to many other unicode characters such as U+00D8 I still get a parse error but the character says it is (U+02DC). 

The funny thing is if I run it through the command line, it works just fine.

Any ideas what is causing this?

[Laura Harker]

I tried adding θ to some JS files loaded via the Java API but couldn't reproduce this error.

Could you give an example of how you're calling the Java API? What platform are you on?

[Scott Chantry]

It wouldn't let me attach the zip file so here is a link: https://drive.google.com/open?id=1oYjxmr0KByNNRZeeC5IQJbSmNY2fbG0S

[Scott Chantry]

I am using a gradle task to execute it. I have attached an example. Unzip and with gradle 5.x installed, run 'gradle minifyjs' and you will see the error.

I just took some sample code from my original js file and put it into test.js.  The funny thing is, if I remove a line of code from a different function in test.js and re-run the task, it will complete successfully. If I put the line of code back in, I get the error again. This is changing a line of code that does not include the special character. Very weird.

On Friday, January 17, 2020 at 2:04:18 PM UTC-7, Laura Harker wrote:

[Tiago Quelhas]

Are you sure your files are UTF-8 encoded? This could be due to a non-UTF8 encoded file (e.g. ISO-8859-1, which is the default for many text editors) being interpreted incorrectly. It's still unclear to me why invoking through the command line vs the Java API would make a difference.

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/915d5a6e-79a8-4bd6-ab7e-dbae59539fb8%40googlegroups.com.

[Scott Chantry]

All of our files are UTF-8 encoded. I'm at a loss as to why it behaves differently as well.  What is even stranger is my last post about how I can remove one line of code at random from the JS file and all of a sudden, the errors disappear even though I didn't change the line where the error is happening.

To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-discuss+unsub...@googlegroups.com.

[Laura Harker]

I tried reproing this. Like Tiago suggested, the error definitely looks related to the file being parsed as ISO-8859-1. Perhaps your Java installation system has ISO-8859-1 as the default encoding, so you need to specify UTF-8.

----

I ran "gradle minifyjs" with your build.gradle on my machine and the minification succeeded.

Then I tried replacing this line (21):

                Reader reader = file.newReader()

to decode via ISO-8859-1:

                Reader reader = file.newReader("ISO-8859-1")

And I got your original error message:

> Task :minifyjs
test.js:69: ERROR - [JSC_PARSE_ERROR] Parse error. Character '¸' (U+00B8) is not a valid identifier start char
function polarToCartesian(cX, cY, r, θ) {
                                      ^

To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/915d5a6e-79a8-4bd6-ab7e-dbae59539fb8%40googlegroups.com.

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/68b8ba6f-9d68-44d6-8cea-17351a5f95aa%40googlegroups.com.

[Laura Harker]

The compiler's command line runner defaults to UTF-8 if no other charset is specified. That would explain why the command line parsing worked for you.

https://github.com/google/closure-compiler/wiki/Flags-and-Options#miscellaneous

[Martin Probst]

If I remember correctly, Java's parsing API, if not explicitly specified, uses an environment variable to pick the default encoding (LC_ALL or so on Unix?). Thus what happens can be a bit magical and differs between systems.

One angle to look at this is that using a reader without explicitly specifying an encoding is a bug.

[Scott Chantry]

You are correct, it wasn't using UTF-8. Explicitly setting the character set in the reader seems to have fixed the issue. Thanks for the help.