When an exception is thrown, it calls getText to get the text of the tokens invloved but the current C++ and Java implemention first fetches the rest of the tokens instead of just using the tokens it already has. C#'s version is correct (fill() is called only when asking for the entire stream's text).
The revently added clang directive cause a new warning for Visual Studio build. Need to include the new code with a directive checking for visual studio
<!--
Before submitting an issue to ANTLR, please check off these boxes:
- [x] I am not submitting a question on how to use ANTLR; instead, go to [antlr4-discussion google group](https://groups.google.com/forum/#!forum/antlr-discussion) or ask at [stackoverflow](http://stackoverflow.com/questions/tagged/antlr4)
- [ x] I have done a search of the existing issues to make sure I'm not sending in a duplicate
Please include information about the expected behavior, actual behavior, and the smallest grammar or code that reproduces the behavior. If appropriate, please indicate the code generation targets such as Java, C#, ... Pointers into offending code regions are also very welcome.
-->
As documented previousTokenOnChannel, should "return -1 if there are no tokens on channel between i and 0." but the C++ version of the runtime returns 0 not -1 as can be seen below:
```
while (true) {
Token *token = _tokens[i].get();
if (token->getType() == Token::EOF || token->getChannel() == channel) {
return i;
}
if (i == 0)
break;
i--;
}
```
Looking at the Java implementation, it would seem the C++ code should instead be:
```
while (true) {
Token *token = _tokens[i].get();
if (token->getType() == Token::EOF || token->getChannel() == channel) {
return i;
}
if (i == 0)
return -1;
i--;
}
```
This bug causes getHiddenTokensToLeft() to miss hidden tokens that come before the first non-hidden token. There would also be a potential bug in CommonTokenStream::LB as the "< 0" case would never happen.
In the orignal PredictionContext::mergeArrays there was a bug on Line 281 where the logic differs from java: It currently is:
bool both$ = payload == EMPTY_RETURN_STATE && a_parent && b_parent;
and should instead match java as:
bool both$ = payload == EMPTY_RETURN_STATE && !a_parent && !b_parent;
This was brought over from the Java runtime in the initial port, but there
it was used as an array capacity hint. We're not using it in Swift so
this is useless.
This is a subclass that only exists to have a different constructor. There
is no need for this construction in Swift, since we have named parameters,
so we can remove the entire subclass and make ATNConfigSet final instead.
Change all the subprocess calls in boot.py to check whether they succeeded,
and set the script status appropriately.
In particular, when our unit tests fail, we need the script to exit
with a failure code so that we actually notice on Travis.
This was always clearly a possibility, looking at the body of the method.
The newly-enabled performance tests expose this bug (and I don't know how
we've gotten away with it otherwise for so long).
The Java runtime also returns null at this point.
The ATNState hashValue and == override are just using the stateNumber field, so
using the Int directly is equivalent, and saves bouncing through those methods.
This also seems to be a correctness issue with the new Hashable protocol changes in
Swift 4.2 (though I admit that I don't know why).
Remove PredictionMode.getStateToAltMap, which was just a stub onto
ATNConfigSet.getStateToAltMap and didn't seem to be doing anything useful.
Avoid adding to closureBusy before all ATNConfig properties are set.
This fixes#2372.
This is a port of c8805ab from the Java runtime. That was PR #1955.
Suppress "Optional" in the output when printing a value in the tests and
some debugging messages.
This is a change in behavior in Swift 4.2 (SE-0054) that implicitly
unwrapped optionals are now seen as plain Optional at runtime, and so
print doesn't implicitly unwrap them any more.
This was working before because calling hashValue on a boxed UInt32 gave
back the value itself. This is apparently no longer true.
It's not something we should have been doing anyway. We were needlessly
boxing the intermediate hash values, and passing them into a generic
method, just to unbox them again.
Fix this by creating a helper method, and calling that directly when
updating intermediate hash values.
This is three instances of flatMap changing to compactMap, and
one instance of UnsafeMutablePointer.deallocate(capacity:) changing
to UnsafeMutablePointer.deallocate().
The antlrcpp::Any::is function should not throw a std::bad_cast
exception if the contained type can't be cast to the requested type,
but should instead just return a boolean result. Add a boolean
parameter to the private getDerived helper function to allow callers
to specify whether or not they want the cast results checked. In the
is() function, pass false for this parameter; in the as() functions,
pass true.
To make it easier to work with the const antlrcpp::Any arguments to
the AbstractParseTreeVisitor class aggregateResult and
shouldVisitNextChild functions, add a public const overload for the
antlrcpp::Any::as member function to return a const StorageType&, and
add a public const overloaded conversion operator returning a const
instance of the type contained within the Any.
Add the private antlrcpp::Any::getDerived function to avoid
duplicating the dynamic_cast of the internal pointer, and call it from
the overloaded Any::as functions and also the Any::is function.
Eric Vergnaud
Mike Lischke
olowo726
Terence Parr
Thomas
WalterCouto
Alexei Averchenko
Gerasimos Dimitriadis
Ralu
Markus Zancolò
You Kaichao
ralf
nxtstep
Ewan Mellor
Alex Mykyta
Steve Vinoski
Sergey Chupov
Sönke Schau
Christopher C. Aycock