ANTLR (ANother Tool for Language Recognition) is a powerful parser generator for reading, processing, executing, or translating structured text or binary files.
BSD-3-CLAUSE License
Bot releases are hidden (Show)
this-escape
warning introduced in JDK 21. (actions, target:java)Published by parrt over 1 year ago
This is primarily change to the Go target itself and its release location, which has moved to https://github.com/antlr4-go/antlr. The code still lives and this repository, but for release purposes we've created a new organization and repository so that Go users can pull versions down according to the repository and label rules
PEP 621
-compliant pyproject.toml
. (comp:build, target:python3)Published by parrt over 1 year ago
The 4.12.0 release is primarily about the new TypeScript target created by @ericvergnaud. There are also a number of fixes to the various targets, as you can see from the descriptions below.
Published by parrt about 2 years ago
Just fixes 4.11.0 release issue. I forgot to change runtime tool version so it didn't say SNAPSHOT.
Published by parrt about 2 years ago
4.11.0 consist primarily:
The details by type and target follow.
@SuppressWarnings("CheckReturnValue")
to prevent error_prone lib errors. (target:java)Published by parrt over 2 years ago
Tiny update to fix build issue where java requirement for runtime was 11 not 1.8.
Full Changelog: https://github.com/antlr/antlr4/compare/v4.10.0...4.10.1
Published by parrt over 2 years ago
This is a very major release with a number of important changes. There have been many valuable contributions, but I welcome @KvanTTT and @jcking as recent "official" major ANTLR contributors. :)
WARNING: Generated 4.10 lexers and parsers are incompatible with code generated by previous versions of ANTLR. You must regenerate all of your code from grammars to use the new runtime. This is true of all targets (except probably javascript).
We have changed the branching structure of the repository. The default branch for this repo remains master
and it is the latest stable release with tags for the various releases; e.g., see release tag 4.9.3. We now do development work in branch dev
between releases and all pull requests should be derived from that branch. The dev
branch is merged back into master
to cut a release and the release state is tagged (e.g., with 4.10-rc.1
or 4.10
.) Visually our process looks roughly like this:
Targets such as Go that pull directly from the repository can use the default master
branch but can also pull from the active dev
branch:
$ go get github.com/antlr/antlr4/runtime/Go/antlr@dev
In order to bring ANTLR more in line with current standard standards for contribution processes, as of 4.10, ANTLR uses the Linux Foundation's Developer Certificate of Origin, DCO, version 1.1. See file https://github.com/antlr/antlr4/raw/master/developer-cert-of-origin.txt . It is simpler than the original contributors license agreement, which required programmers to sign the contributors.txt
file, which has now moved to file historical-contributors-agreement.txt .
Each commit in pull requests must have a "signature", which is simple as using -s
(not -S
) on the git commit command:
$ git commit -s -m 'This is my commit message'
Github's pull request process enforces the sig and gives instructions on how to fix any commits that lack the sig. See https://github.com/apps/dco for more info.
ANTLR not only generates recursive-descent parsers; it generates a state machine called an augmented transition network (ATN) in serialized form as a bunch of integers stored in the generated parser and lexer files. This serialization format was changed for 4.10 to remove a size limit on the supported ATNs. See https://github.com/antlr/antlr4/pull/3591.
The key point here is that we changed the version number stored inside the serialization format and so, in order to use this new version of ANTLR, you must regenerate all of your lexers and parsers using the 4.10 tool and then use the new runtime. Parsers generated with 4.10 or not compatible with previous versions of the runtime.
Going forward, we are using Java 11 for the source code and the compiled .class files for the ANTLR tool. The Java runtime target, however, and the associated runtime tests use Java 8 (bumping up from Java 7).
The JS target has been substantially reworked.
caseInsensitive
option now.The following report is generated by scripts/github_release_notes.py
.
AnyObject
instead of class
. (target:swift)late
modifier for Dart generated context classes (target:dart)Full Changelog: https://github.com/antlr/antlr4/compare/4.9.3...4.10
Published by parrt almost 3 years ago
go.mod
to go runtime module (comp:build, target:go)Published by parrt over 3 years ago
Moved away from travis-ci.com.
Published by parrt almost 4 years ago
Published by parrt almost 4 years ago
Thanks to @lingyv-li, we have a DART target!
Published by parrt almost 5 years ago
Thanks to @marcospassos, ANTLR 4.8 introduces a PHP target! See PHP PRs
Published by parrt almost 6 years ago
contextSuperClass='antlr4::RuleContextWithAltNum'
doesn't work (target:cpp)_loadString
parameter (target:javascript)Published by parrt almost 7 years ago
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)Published by parrt over 7 years ago
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:
Published by parrt almost 8 years ago
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)Published by parrt over 8 years ago
contextSuperClass
. All parse tree internal nodes will derive from this. Default is ParserRuleContext
. Should derive from ultimately RuleContext
at minimum.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
interfaceComplete 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.
Published by parrt over 8 years ago
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.
Published by parrt over 9 years ago
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.
Published by parrt over 9 years ago
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.