The call to stream.read needs to use buffer.count, not buffer.capacity,
as the maxLength. Otherwise, some bytes get dropped on the floor and the
stream is corrupted.
Remove the code to pad self.data back to up to its previous capacity when
copying data at the end of release. This came over from the Java port, but
I don't think it makes sense in Swift, given the copy-on-write Array
value semantics. Instead, just copy the tail of the buffer if there is
anything left to read (i.e. self.data gets smaller) and when there is nothing
in the buffer to read, reset to the specified bufferSize (i.e. self.data
goes back to the specified self.bufferSize.
Remove debug print statement that was accidentally left in.
- Add "explicit" to Interval(size_t, size_t) constructor.
- Change an IntervalSet constructor to delegate part of the construction
- Add "explicit" to Interval(size_t, size_t) constructor.
- Change an IntervalSet constructor to delegate part of the construction
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 avoids hitting the Microsoft server every time. The download isn't
super-reliable, so this should help with build reliability.
This extends the cache timeout, because the package is large and the
upload was timing out.
token stream that triggered the error.
These are useful for error diagnostics, but if client code wants to throw
the RecognitionException but discard the parser and token stream, then
the fields in RecognitionException need to be cleared.
This adds RecognitionException.{clearRecognizer,clearInputStream} so that
client code can clear those fields if desired. It also makes
RecognitionException.ctx weak, so it will go nil at the same time as
the parser is discarded.
This was causing all the tokens, streams, and lexers to be retained. The
primary cycle was because of the backreference at CommonToken.source, and
the fact that the token streams buffer the tokens that they create.
Fix this by replacing the use of a (TokenSource?, CharStream?) pair with
TokenSourceAndStream, which does the same job but references its fields
weakly. This means that Token.getTokenSource() and Token.getInputStream()
will return valid values as long as you retain the lexer / stream elsewhere,
but a Token won't itself retain those things.
This was causing the entire parser to be retained, resulting in a large
memory leak.
This fix simply changes the reference from ParserATNSimulator to Parser
to be unowned.
Ditto between Lexer and LexerATNSimulator, except this reference is made
weak because LexerATNSimulator.recog is nullable. (That difference is
dubious IMHO, but I'm leaving it intact for now.)
Terence Parr
Jason Mooberry
Ewan Mellor
gendalph
Jan Mikkelsen
Maurice van der Pot