ANTLR (ANother Tool for Language Recognition) is a powerful parser generator for reading, processing, executing, or translating structured text or binary files.
Thanks to @lingyv-li, we have a DART target!
Thanks to @marcospassos, ANTLR 4.8 introduces a PHP target! See PHP PRs
contextSuperClass='antlr4::RuleContextWithAltNum'
doesn't work (target:cpp)_loadString
parameter (target:javascript)ANTLR version 4.7.1 is a minor release but with lots of little improvements and bug fixes. You can find the pull requests grouped by target language below. Also, please find below the contributor list (auto-generated from the issues and pull request).
mode
s into other lexer grammars [...]
-o
and -lib
commandline options didn't always do the obvious thing and in fact presented some problems. With clean that up but requires a new -Xexact-output-dir
command line option to enable it to avoid breaking tools built on previous versions of ANTLR [...]
new
keyword to return proper InputStreams (target:javascript, type:bug)ANTLR version 4.7 is a major release with many improvements and bug fixes.
The primary improvement is that ANTLR and all code generation targets can now handle full 21-bit unicode thanks to the superhuman effort of Ben Hamilton, @bhamiltoncx. After much thought concerning the "create stream" interface, I have decided on the following end result: C++, Python, Go, and Swift APIs didn't need any changes to support full Unicode code points, so I decided to leave those alone. Java, C#, and JavaScript runtimes required changes. Rather than gutting and changing the interface of the previous ANTLRFileStream etc..., I have deprecated those and introduced a CharStreams.fromXXX factory style interface for creating streams. For example, CharStreams.fromFileName("foo.txt"))
. See the new unicode documentation and a complete list of all pull requests related to Unicode.
UnbufferedCharStream
for Java and C# targets was upgraded to use UTF-8 rather than the locale default encoding; they further support U+10FFFF Unicode code points. C++ is the only other target with the unbuffered stream and it worked as-is.
In addition to creating CharStreams
capable of supporting 21-bit Unicode, we added notation for Unicode code points beyond 16 bits (4 hexadecimal digits). The usual notation \uABCD
still works for the basic code points but you can now use \u{1FFFF}..\u{10FFFF}
to access the full range:
You can also include all characters matching Unicode properties such as [\p{Emoji}]
:
The C# target now supports .NET Core Support, thanks to David Neumann @lecode-official and Dong Xie @xied75!
We did quite a bit of cleaning up in the lexer escape char and char set areas (big thanks to Ivan Kochurkin @KvanTTT):
The Go runtime was significantly speeded up.
The XPath tree matching library used an ANTLR grammar itself, which caused a cyclic dependency in the build whereby ANTLR version v was required to build version v. I implemented a handbuilt lexer to get rid of this dependency on a grammar: XPathLexer not updated in release process, Fixes #1620. Make handbuilt lexer to avoid cyclic dependence of tool and plugin.
The Java, Swift, and C++ targets have added a hook to the construction of parse tree leaf nodes: factor out the creation of error nodes and terminal nodes in the parser. Code new TerminalNodeImpl(..)
and new ErrorNodeImpl(...)
instead now calls a few factory methods in the Parser that you can override in your application.
C++ target:
JavaScript target:
Python2/3:
C#:
Go:
Java:
Swift:
Tool or all-target-runtime related:
ANTLR version 4.6 is a major release with many features and bug fixes.
e : e '*' e | INT ;
). Sam noticed that the parsing engine detected an ambiguity between two choices and resolved it properly but that both would lead to a valid parse. It turns out that the first choice is what led to really slow parsing but the second choice is much faster and still yields a valid parse. Most targets have added that improvement. Here is the discussion of the issue and solution and the primary patch for java.sync()
calls back in for LL(1) decisions. (code-gen, error-handling)sync()
calls back in for LL(1) decisions. (code-gen, error-handling)contextSuperClass
. All parse tree internal nodes will derive from this. Default is ParserRuleContext
. Should derive from ultimately RuleContext
at minimum.
Java target can use contextSuperClass=org.antlr.v4.runtime.RuleContextWithAltNum
for convenience. It adds a backing field for altNumber
, the alt matched for the associated rule node.getMaxTokenType()
to Vocabulary
interface
Complete list of pull requests for 4.5.3 but most of those are fixing bugs.
Complete list of issues closed/solved for 4.5.2.
Complete list of pull requests for 4.5.2 but most of those are fixing bugs.
Summary: some clean up in JavaScript and Python targets. Minor issues in Java/jar.
Complete list of issues closed/solved for 4.5.2.
We fixed number of important bugs but also combined the various target repositories, such as antlr/antlr4-python2, into the main antlr/antlr4 repository.
For the Java target only, there is also a new feature: a parser interpreter that tracks which alternative or label was match for a particular parse tree node, which is often useful during debugging. It is used in the 1.7 release of the ANTLR Intellij Plugin.
antlr4-python2
into the main antlr4
repo so that everything is now included in a single spot.org.antlr.v4.runtime.misc.TestRig
has moved to org.antlr.v4.gui.TestRig
but we left a proxy in so that org.antlr.v4.runtime.misc.TestRig
still works. The org.antlr.v4.runtime.tree.gui
package moved to org.antlr.v4.gui
in the tool area from the runtime. A few classes from org.antlr.v4.runtime.misc
had to move. Convenience methods for saving/viewing parse trees were moved from RuleContext
(parse tree) and org.antlr.v4.runtime.tree.Trees
to org.antlr.v4.gui.Trees
.You can view all Issues fixed in 4.5.1, all pull requests merged and all commits for this release.
Download the ANTLR tool and all target runtimes at the antlr.org site.
The Java jars are OSGi compatible so you should be able to use them within Eclipse.
As of 4.5, the standard distribution of ANTLR can generate code in the following languages:
In addition, the following languages are supported by standalone release(s) of the tool.
We fixed number of important bugs but also combined the various target repositories, such as antlr/antlr4-python2, into the main antlr/antlr4 repository.
For the Java target only, there is also a new feature: a parser interpreter that tracks which alternative or label was match for a particular parse tree node, which is often useful during debugging. It is used in the 1.7 release of the ANTLR Intellij Plugin.
antlr4-python2
into the main antlr4
repo so that everything is now included in a single spot.You can view all Issues fixed in 4.5.1, all pull requests merged and all commits for this release.
Download the ANTLR tool and all target runtimes at the antlr.org site.
The Java jars are OSGi compatible so you should be able to use them within Eclipse.
As of 4.5, the standard distribution of ANTLR can generate code in the following languages:
In addition, the following languages are supported by standalone release(s) of the tool.