Contrary to Python3, the lexers and parser generated for Python2 target
support only relative imports which causes a failure in case of
standalone scripts. The patch adapts these imports to work in both
cases.
Although, both lexer and parser grammars can have a custom super
class set, but only the generated parser sources were prepared to
import these classes. The patch makes custom lexer ancestor
classes imported, too.
Until now, the generated Python3 code imported the custom parser
superclasses relatively. However, this only worked in Python3 if
the module was inside a package, since relative imports rely on
__name__ to determine the current module's position in the package
hierarchy. In case of a standalone script, this was always __main__
and hence these relative imports failed.
The patch handles this issue them same way as it is handled by
listener imports.
Change to support import of lexer grammars containing modes into other
lexer grammars. The semantics for this are,
* sets of channels from all grammars are merged
* rules of modes found in an imported grammar which are in the root
grammar are merged into the root grammar mode.
* modes which are not in the root grammar are added to the root
grammar, excluding modes which become empty due to a re-definition of
rules in the root grammar.
Add an accessLevel parser option. Use this to specify the access level
(public, etc) used on the classes and protocols in the generated
parser / lexer / listeners. This required adding the option to
tool.Grammar.parserOptions so that it was known as a valid option, and
to codegen.model.{Recognizer,ListenerFile,VisitorFile} so that it was
available to the template in all the necessary contexts.
The Swift template has been extended to recognize this option, and generate
classes and members using "open", "public" or "internal" as appropriate.
This is only fully implemented for Swift. The option is generic, but
the language-specific templates will need to be updated for any language
that would like similar support.
Closes#1597.
Add the column to the location; this is something that GCC and other
GNU tools do, and is obviously useful for IDEs.
Move the message ID so that it reads e.g. "... [error 50]". This mimics
GCC's [-Wformat] kind of thing and is more obvious than the (50) that we
were using before.
When the default "antlr" message format is used, ErrorManager deliberately
only includes the filename in any error message, not the full path, to
keep the messages short. However, if the error message is intended to be
parsed by an IDE, this is no good.
Address this by printing the full path when using alternate message formats.
There are two formats available today -- "gnu" and "vs2005". I think it's
reasonable to assume that people would use these for IDE compatibility, and
so using the full path for these is appropriate. Also, they didn't work
until very recently, so this isn't breaking any existing behavior.
ErrorManager.setFormat was being called before the command line options
were parsed in handleArgs. This meant that setFormat was always called
with the default, and so the command line option never took effect.
This option apparently only worked for 2.5 hours on Sep 6 2012 ;-)
Closes#992.
If the specified output path was a file and not a directory, the error
handling intended to invalidate outputDirectory, but due to an apparent
copy-paste error, it invalidated libDirectory instead.
This removes the generic parameter on RecognitionException, to make it
easier to handle them. This means that we no longer need to store them as
AnyObject and cast them back again. To do this, we add RecognizerProtocol,
which is a non-generic equivalent of the Recognizer interface (at least, the
parts of it that we need for error handling).
Remove all paths where the RecognitionException subclasses were throwing
exceptions in their initializers. This is just insane.
This has been ported over from the Java code, but it was deprecated there.
There's no point having it in the Swift runtime because we don't have the
legacy code to support. Also, it wasn't implemented properly, so it
never worked.
Remove {DFA,IntervalSet}.toString(_:[String?]?)
and the inits in ParserInterpreter and DFASerializer for the same reason.
Switch the unit tests to use the alternate toString(_:Vocabulary).
This fixes some hangovers from the port from Java:
* unnecessary type annotations;
* failure to use "if let" for nil checks;
* comments with Java code in them;
* a couple of fields that should have been declared private;
* some whitespace issues.
No semantic change.
- A wrong check for EOF has been corrected in the UnbufferedTokenStream (now using the correct data type for the cast to avoid warnings).
- The interpreter data write function no longer implicitly writes out imported grammars. Grammars are merged and hence contain everything from imported grammars already. If interpreter data for an imported grammar is required pass that grammar explicitly to the ANTLR tool.
Especially when you want to use LexerInterpreter and/or ParserInterpreter in any of the non-Java targets you have to provide the ATN and other data. The classes to generate these values are not in the runtime, however. Hence we need a way to tell ANTLR to produce that in a way that can be consumed by all targets.
This patch adds a new command line parameter (-interpreter) which causes ANTLR to parse the given grammars as usual and then let it generated a file for each grammar with the required interpreter values. A new InterpreterDataReader class has been added to the Java + C++ runtimes. This class can load the data file (a plain text file) and generate the structures that can directly be fed to the interpreters.
Renata Hodovan
Eric Vergnaud
parrt
Ivan Kochurkin
Joseph Smith
Daniel Halperin
Stephen Vance
Oran Epelbaum
Nicolas
Ewan Mellor
Terence Parr
Mike Lischke
Jason Mooberry
rlfnb
Andrew Brampton
Bráulio Bezerra
Venkat Peri
Sergey Parshukov
Ben Hamilton