When I trying to generate javadoc - I get some meaningless errors like encoding error in non-javadoc comments. Maybe exists some command-line argument or something for ignore errors and generate docs anyway?
Error example (It's even not in javadocs, just inline Cyrillic comment)
GroupsSorter.java:83: error: unmappable character for encoding Cp1251
//Р?тоговый СЃРїРёСЃРѕРє
^
Related
I was trying to fix some weird PDF Unicode remapping issues when I was stuck by this issue where adding an ENQ Unicode character to some part of the code prevents you from compiling the code and IDE will present you with what I think is a false alarm(error).
Consider this example of completely valid Kotlin code and let's call it Program A where unfortunately you can't see the actual characters here between apostrophes but believe me there's a character in there (if you copy this code into your IDE you can see those characters).
package yamin
fun main() {
val foo = mutableListOf('')
//val bar = mutableListOf('')
println(foo)
}
However, you can see them in the picture.
But if you decide to compile this code somehow IDE fails to compile it and claims that there are 'Too many characters in a character literal' in line 4.
What is interesting is that the sheer presence of ENQ character even in a comment line prevents the IDE to compile this code and if you remove line 5, therefore, removing the presence of ENQ character then you can compile this code (let's call it Program B), observe:
Anyway if you decide to remove line 4 in Program A and uncomment line 5 then you can compile that code too (let's call it Program C).
So let's recap Program A is invalid and line 4 is the culprit of the invalidity but removing line 5 in that program which leaves us with Program B could be compiled successfully and this situation is repeated for Program C.
What am I missing here?
It looks like a bug in Kotlin compiler, because the error happens even if the code is compiled with command-line:
kotlinc enq.kt -include-runtime -d enq.jar
Also, this simple program gives different results on the playground (correct):
and locally (incorrect):
As a workaround you may use Unicode escape sequence syntax (at least for ENQ symbol):
Playground does the same thing when passing this code to the server, so the compiler gets sanitized code:
I'm trying to use ANTLR 3.1.3 on a system with local EBCDIC char set
Even a simple grammar like this:
lexer grammar test;
GENERIC_ID
: (LETTER)*
;
fragment LETTER
: 'a' .. 'z'
;
results in these errors during the initial compile (java org.antlr.Tool test.g):
error(10): internal error: problem parsing group <unknown>: line 1:1: unexpected char: 0x7 : line 1:1: unexpected char: 0x7
org.antlr.stringtemplate.language.GroupLexer.nextToken(GroupLexer.java:233)
antlr.TokenBuffer.fill(TokenBuffer.java:69)
antlr.TokenBuffer.LA(TokenBuffer.java:80)
antlr.LLkParser.LA(LLkParser.java:52)
antlr.Parser.match(Parser.java:210)
org.antlr.stringtemplate.language.GroupParser.group(GroupParser.java:120)
org.antlr.stringtemplate.StringTemplateGroup.parseGroup(StringTemplateGroup.java:792)
org.antlr.stringtemplate.StringTemplateGroup.<init>(StringTemplateGroup.java:274)
org.antlr.stringtemplate.PathGroupLoader.loadGroup(PathGroupLoader.java:67)
org.antlr.stringtemplate.StringTemplateGroup.loadGroup(StringTemplateGroup.java:969)
org.antlr.stringtemplate.StringTemplateGroup.loadGroup(StringTemplateGroup.java:955)
org.antlr.codegen.CodeGenerator.loadTemplates(CodeGenerator.java:198)
org.antlr.codegen.CodeGenerator.genRecognizer(CodeGenerator.java:292)
org.antlr.Tool.generateRecognizer(Tool.java:607)
org.antlr.Tool.process(Tool.java:429)
org.antlr.Tool.main(Tool.java:91)
error(10): internal error: test.g : java.lang.IllegalArgumentException: Can't find template outputFile.st; group hierarchy is [null]
org.antlr.stringtemplate.StringTemplateGroup.lookupTemplate(StringTemplateGroup.java:507)
org.antlr.stringtemplate.StringTemplateGroup.getInstanceOf(StringTemplateGroup.java:392)
org.antlr.stringtemplate.StringTemplateGroup.getInstanceOf(StringTemplateGroup.java:404)
org.antlr.codegen.CodeGenerator.genRecognizer(CodeGenerator.java:314)
org.antlr.Tool.generateRecognizer(Tool.java:607)
org.antlr.Tool.process(Tool.java:429)
org.antlr.Tool.main(Tool.java:91)
the grammar file seems to be processed appropriately, but it appears something internal is causing some problems. No matter what chars I use in the grammar file, the illegal char always seems to be 0x7.
Can I not compile ANTLR on a system with local EBCDIC char set? Any suggestions?
Update: it appears the problem lies in the template files (.stg files). If I convert the files in the codegen/templates directory to EBCDIC (also ANTLRCore.sti) then the compilation seems to complete. Is there a way to tell java/antlr to not read these files in local encoding? Either that or are these template files available in other encodings? Otherwise I am forced to convert by hand and replace each one
I am using the Uncrustify plugin for Xcode5 (BBUncrustifyPlugin) to format my code nicely. However when formatting the active file it gives the errors:
Uncrustify Formatter error:
Parsing: XDImageViewController.m as language OC
XDImageViewController.m:33 Unmatched NEWLINE
Looking at this line all I have is a single hash # followed by a new line. like so:
#
#pragma mark - Section header
#
Can anyone tell me if there is a way to get Uncrustify to ignore this error or work around it? I don't see why a hash should cause problems.
Thanks.
The TestDriver in ANTLRWorks2 seems kind of finicky about when it'll accept a grammer without and explicit EOF and when it will not. The Hello grammar in the ANTLR4 Getting Started Guide doesn't use EOF anywhere, so I inferred that it's better to avoid explicit EOF if possible.
What is the best practice for using EOF? When do you actually need it?
You should include an explicit EOF at the end of your entry rule any time you are trying to parse an entire input file. If you do not include the EOF, it means you are not trying to parse the entire input, and it's acceptable to parse only a portion of the input if it means avoiding a syntax error.
For example, consider the following rule:
file : item*;
This rule means "Parse as many item elements as possible, and then stop." In other words, this rule will never attempt to recover from a syntax error because it will always assume that the syntax error is part of some syntactic construct that's beyond the scope of the file rule. Syntax errors will not even be reported, because the parser will simply stop.
If instead I had the following rule:
file : item* EOF;
In means "A file consists exactly of a sequence of zero-or-more item elements." If a syntax error is reached while parsing an item element, this rule will attempt to recover from (and report) the syntax error and continue because the EOF is required and has not yet been reached.
For rules where you are only trying to parse a portion of the input, ANTLR 4 often works, but not always. The following issue describes a technical problem where ANTLR 4 does not always make the correct decision if the EOF is omitted.
https://github.com/antlr/antlr4/issues/118
Unfortunately the performance impact of this change is substantial, so until that is resolved there will be edge cases that do not behave as you expect.
So I have a symbol: π in the strings file and it turnes out that due to it I cannot successfuly compile to fatal:
Copy EN.strings
Command /Developer/Library/Xcode/Plug-ins/CoreBuildTasks.xcplugin/Contents/Resources/copystrings failed with exit code 1
If I remove π it's fine. The strange thing is that even if I put π in the comment it still won't compile.
what to do?
Thankx
If you can find the Unicode value of the character, you could escape it in the following manor:
NSString *str = #"\u00F6"
And Java (just for comparison):
String str = "\u00F6";
Although I'd imagine that the compile issue relates to the character being from a different encoding to the specified encoding of your source file. I believe the compiler will interpret your source as UTF-8 by default.
Make sure your strings file is using a Unicode encoding, and make sure the string is quoted; this has solved the issue for me in the past.