Testability and build improvements #2405
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ewanmellor
force-pushed
the
testability-and-build-improvements
branch
3 times, most recently
from
42adcd8
to
500cfba
Compare
|
Does this fix previous build? Looks like that failed: |
|
@ewanmellor done! merged #2047 |
ewanmellor
force-pushed
the
testability-and-build-improvements
branch
from
500cfba
to
deeb74c
Compare
…e value. 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.
Thanks, Maven.
This means that we will see the errors if Surefire is bailing for any reason.
This means that if you build in an unclean source tree, you don't end up with intermediate classes in the jar. (This hasn't broken anything that I noticed, but it bloats the jar and I wanted to make sure it wasn't messing anything up.) This excludes .build (the Swift runtime's build directory), target (the Java runtime's build directory) and Swift/*.xcodeproj (which is not in the source tree but can be created by devs who are using Xcode).
Change the unit test asserts so that we can see all the values in the event of a failure. When debugging an error, it's useful to see both the stdout and stderr for the failure. Previously we would only see one or the other (whichever one failed the assert). This adds a helper function BaseRuntimeTest.assertCorrectOutput. This also removes SpecialRuntimeTestAssert, which has not been used for 2 years.
We get much more info if we let the exception rise to the top level.
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.
Add -f netstandard1.3 to the dotnet build command used on Travis. This has been necessary since PR antlr#2024, and the build has been silently failing all this time.
Test scripts that ignore errors aren't very helpful.
ewanmellor
force-pushed
the
testability-and-build-improvements
branch
from
deeb74c
to
443a1d2
Compare
|
I've rebased this on top of PR #2408, which should fix the test failures. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Miscellaneous testability and build improvements.