-
Notifications
You must be signed in to change notification settings - Fork 5.8k
8332474: Tighten up ToolBox' JavacTask to not silently accept javac crash as a failure #19972
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
👋 Welcome back jlahoda! A progress list of the required criteria for merging this PR into |
@lahodaj This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 71 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. ➡️ To integrate this PR with the above commit message to the |
|
||
@Override | ||
public Result run(Expect expect, int exitCode) { | ||
if (exitCode == 4) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess we never expect javac
to crash, and should not be able to test that it does, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not too worried about a test that would intentionally crash javac, and would need to test for that. It is not clear to me what would be the purpose of the test. And, assuming this need would indeed be rare, there are other ways to test for that. So, I opted for a more strict approach. OTOH, I don't have a too strong opinion on this, so I can re-allow exit code 4 here if desired.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
The parent pull request that this pull request depends on has now been integrated and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout JDK-8332474
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
/integrate |
Going to push as commit 559826c.
Your commit was automatically rebased without conflicts. |
Tests for javac use several test frameworks, and one of them is the "toolbox", which provides
JavacTask
that allows to conveniently run javac on a given set of sources. The problem withJavacTask
is that, by default, when a compilation failure is expected, javac crash (exit code 4) is tolerated by theJavacTask
. And the test must manually select a specific exit code to overwrite this behavior.This then leads to bugs like https://bugs.openjdk.org/browse/JDK-8335385, which are silently ignored by
JavacTask
.The proposal herein is to tighten up the
JavacTask
, and effectively disallow exit code 4 forJavacTask
(but permit any other exit code, as javac is using several exit codes). The base implementation inAbstractTask
is changed to use a validator for the exit codes, which is then leveraged byJavacTask
.This patch depends on PR #19969, as that fixes JDK-8335385, where the javac crash is ignored. It also tweaks module attribution to not leave empty
JCModuleDecl.sym
for duplicate modules, and set it to an erroneous module. The empty (null
) symbol here crashes javac in thetest/langtools/tools/javac/modules/MultiModuleModeTest.java#testDuplicateModules
, and the test wouldn't pass with this more strictJavacTask
.Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/19972/head:pull/19972
$ git checkout pull/19972
Update a local copy of the PR:
$ git checkout pull/19972
$ git pull https://git.openjdk.org/jdk.git pull/19972/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 19972
View PR using the GUI difftool:
$ git pr show -t 19972
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/19972.diff
Webrev
Link to Webrev Comment