These are the unit tests that are written in Swift, not the more
in-depth runtime-testsuite tests (we were always running those).
I don't know why JAVA_HOME isn't set during run-tests-swift.sh, but it
isn't. Set it, since runtime/Swift/boot.py expects it as part of the
parser generation.
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.