[antlr-interest] Integrating Antlr-3.0b5 with VS2005 C# projects

[Benoit Miller]

Kay Roepke wrote:
> Benoit Miller wrote:
>> [...] sometimes antlr gives an empty location 
>> field, or non-translated locations, such as this example:
>>
>>   SimpleCalc.g(39,7): error 100: syntax error: antlr: 
>> SimpleCalc.g:39:7: unexpected token: foo
> 
> This is due to the fact that some of the error messages come from the 
> parsers for ANTLR itself, which are written in ANTLR v2. The error 
> messages (and thus their formatting) will be better once v3 is built 
> with v3. It just wasn't justifiable to invest a lot of work into this, 
> if it will go away some time in the future anyway...

I should have chosen my example more carefully. Partially-translated 
messages aren't really a problem, it's the ones without any location 
that are (I'll mention below why that's important).

For example, changing the first line of a grammar to use a different 
grammar name (without renaming the file) yields the following message:

  : error 8: file SimpleCalc.g contains grammar Foo; names must be identical

Antlr knows the file that the error is in (it even tells us!) but it is 
not formatted correctly so we cannot directly go to the error in VS. 
With the posted version of the MSBuild snippet, we end up redirected to 
a non-existant "EXEC" file (which is the name of the MSBuild task used 
to launch antlr).

> If there's an error it shouldn't generate stuff. I thought 
> there were some sets of messages that inhibit code generation, should be 
> in ErrorManager.java. Do you have a list, so we could add tests and fix 
> those cases?

One easy repro case is to remove the end semicolon from a parser or 
lexer rule. Antlr will generate an error (and return -1) but still 
generate the code, thwarting further dependency checks from the build 
system.

I remember Terence saying in the antlr3 presentation that one of the new 
features is that antlr3 is much more resistant to missing/extra tokens, 
perhaps this is a misfeature after all? :)

> A different thing that came up a while ago was that org.antlr.Tool 
> doesn't give a proper return value when exiting with an error. This 
> breaks the "stop build on fail" feature of Xcode, at least (I've been 
> bitten by that in my Xcode support). It also has implications when 
> embedding org.antlr.Tool in Java IDEs, since we can't just exit.
> How does Visual Studio deal with this (exit codes from tools, I mean)?

Yes, I've seen this happen during my MSBuild experiments, but I don't 
remember what caused this behavior. I haven't seen this at all since...

It seems Visual Studio simply ignores nonzero return codes if it cannot 
find a correctly-formatted error message. If you don't use the 
"-message-format vstudio" option but get an error in antlr, VS will 
/not/ stop the build nor trigger an error (but it is clearly shown in 
the buildlog!).

Another odd behavior of Visual Studio is that you must *never ever* open 
the generated files in VS! If you do, then VS2005 compiles the code that 
was in the window at the time the build was started (instead of the 
newly-generated version) and we are back to the original dependency 
problem. Sigh!

It's actually quite possible that this "feature" is the reason the 
classic "custom build step" solution failed when I tried it... Aargh.

I think adding an "<AutoGen>True</AutoGen>" child tag to the Compile tag 
of the generated files will solve this problem, but the property isn't 
documented so YMMV. I will keep testing and update the Wiki accordingly.

Ben.