These classes throw exceptions if the instance is read-only, and only in
that case. This means that there is no need for us to propagate exception
declarations in the cases where we have guaranteed by construction
that the instance is writable. In particular, this means that IntervalSet
and ATNConfigSet's constructors won't throw exceptions(!) The set options
that return a new set (e.g. complement) no longer throw either.
To help with this, this cset adds BitSet.firstSetBit(). This is equivalent
to BitSet.nextSetBit(0), but is guaranteed not to throw an exception.
As a consequence, ANTLRErrorListener / DiagnosticErrorListener no longer
throw exceptions through any of their functions (syntaxError and report*),
and DefaultErrorStrategy can no longer throw exceptions as part of its
internal operations (though of course it can still throw exceptions if
recovery fails and a real parsing error needs to be reported).
Also, LL1Analyzer no longer throws exceptions at all, and so ATN.nextTokens
doesn't throw either.
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.
These were ported over from the Java runtime, but they were all deprecated
there, and were commented as such here. There is no point having them in
the Swift runtime because we don't have legacy code to support.
For some reason, possibly the new images that AppVeyor rolled out on Oct 22,
our AppVeyor tests now fail immediately, with msbuild complaining that there
are multiple solutions in the repository.
Address this by not using the default AppVeyor build section, but calling
msbuild ourselves explicitly in the build_script section. This way, we can
specify which .slns we want to build. I have specified the runtime and
runtime-testsuite Antlr4.vs2013.slns; the other ones didn't work for me in
this configuration.
Also, these builds were previously running with low / zero logging. As
far as I can tell, this gave AppVeyor no way to know whether the build has
succeeded or not. It certainly gives no way to diagnose any failures that do
occur. I have dialed the logging up on everything.
Also, remove the os declaration. That appears to be well out of date, and
isn't on AppVeyor's list of images any more. I presume that we've been
using their default image for some time.
Use Swift's overflowing operators rather than multipliedReportingOverflow
etc.
Use UInt32 for the hash values. This matches how MurmurHash3 is generally
defined (e.g. on Wikipedia).
Add support for decoding Strings (UTF-8, then little-endian) and hashing
the resultant UInt32 values.
Add a test set, using test patterns from Ian Boyd (public domain).
This uses Travis's new(ish) Ubuntu Trusty image, and changes the
version number of the Swift binaries that we download.
We now install clang-3.6. This is not the default on Trusty, but
it's required by the Swift 4.0 toolchain.
This also removes the lines to upgrade libicu-dev and sqlite3. These
are sufficiently up-to-date in the Trusty image.
We require Xcode 9 for the Swift target, and the C++ and .NET tests
shouldn't care either way.
We no longer need to install cmake: this is already in the Travis
Xcode 9.0 image (and it barfs if we try to install it again).
We no longer need the rvm bug workarounds; a newer version of rvm is
in the Xcode 9.0 image so this is no longer a problem.
The openssl package is already installed and up-to-date now, so there is
no need to install that.
These changes mean that we don't need before-install-osx-cpp.sh
or before-install-os-swift.sh at all, and before-install-osx-dotnet.sh
gets a bit shorter. .travis.yml gets a small change to handle the
fact that some platform / target combos don't need before-install any more.
SwiftPM has changed its default layout for new packages (i.e. when we
use "swift package init --type executable" during the test). It now is
<projectName>/Sources/<projectName>/main.swift, so we need to adjust the
paths appropriately.
This includes a small change to print stdout as well as stderr if a
unit test fails to build. swift-build-tool takes the compiler subprocess's
stderr and puts it on stdout. *sheesh* This meant that we were losing
critical error messages.
Remove a number of generic type constraints, since these can now
be inferred by the compiler.
Match the syntax change when passing a tuple into a function (adding
an extra set of parens).
Change filterPrecedencePredicates to avoid a now-illegal cast.
Match the renames truncatingBitPattern -> truncatingIfNeeded,
multiplyWithOverflow -> multipliedReportingOverflow, etc. In
some cases the multiplyWithOverflow calls are replaced by
overflowing operators (e.g. &*) instead.
Ewan Mellor
Terence Parr
JavaDDD
rlfnb
Mike Lischke
Hanzhou Shi
simkimsia