-
Notifications
You must be signed in to change notification settings - Fork 6.2k
8351958: Some compile commands should be made diagnostic #25150
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
8351958: Some compile commands should be made diagnostic #25150
Conversation
|
👋 Welcome back mchevalier! A progress list of the required criteria for merging this PR into |
|
@marc-chevalier 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 376 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 |
|
@marc-chevalier The following label will be automatically applied to this pull request:
When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command. |
Webrevs
|
TobiHartmann
left a comment
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.
Thanks for the detailed description. The fix looks good to me. I just added a few minor suggestions for improvement.
| register_command(typed_matcher, option, error_buf, sizeof(error_buf), true); | ||
| if (*error_buf != '\0') { |
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.
@marc-chevalier I know that you follow existing patter. But may be register_command() should return boolean result if it succeeded or not so you can check it instead of loading value from buffer.
scan_value()and scan_option_and_value() may need to do the same.
Note, print_parse_error() has assert to check that error message is not empty.
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.
It's fun you suggest that: it was my first version, but it felt like it was a lot more diff than what my PR version has. Happy to use a returned boolean.
I've made sure to rename function with temporary name not to miss any call site where the returned bool would be ignored, and renamed back. I also removed returns at the end of function not to miss any path: reaching end of function without a return is a warning (becoming error) at compile-time.
I've also removed a bit of now-obviously dead code.
vnkozlov
left a comment
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.
Look nice.
TobiHartmann
left a comment
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.
That looks good to me too.
|
/integrate Thanks @vnkozlov & @TobiHartmann! |
|
Going to push as commit e348aa0.
Your commit was automatically rebased without conflicts. |
|
@marc-chevalier Pushed as commit e348aa0. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Error when using a
CompileCommandthat is an alias for a diagnostic option when-XX:+UnlockDiagnosticVMOptionsis not provided.The argument processing works this way:
CompileCommand, each option is added to a\n-separated string. At this step, if a flag is diagnostic but-XX:+UnlockDiagnosticVMOptionsis not provided, then an error message is emitted, argument parsing fails and the VM terminates. Yet, the value ofCompileCommandis still an unparsed list of string.CompileCommandis parsed. For some of them, the value of regular flag is used as the default value, and as far as I know, it's the only mapping betweenCompileCommandand the equivalent flag. Moreover, at this point, the order of the various command line arguments is lost: it is not possible to know whichCompileCommandcomes before or after the-XX:+UnlockDiagnosticVMOptions.Moreover,
CompileCommandare parsed in the same way as compiler directives coming from a file. If we complain about diagnosticCompileCommand, we should also when coming from a directive file, for consistency. But then, while the relative order ofCompileCommandand-XX:+UnlockDiagnosticVMOptionsis lost, it simply makes no sense to compare the ordering of command line arguments and directives from a file.So, before the difficulty and the relative lack of sense, I defaulted to ignore the ordering requirement. And by using the
CompileCommanderror reporting mechanism, we get an error that is consistent with otherCompileCommand-parsing related errors, e.g.The other problem is how to identify that a
CompileCommandis an alias for a diagnostic flag. I refrained from hardcoding the list, but there is no nice mapping stating "this is an alias for...", only the default value for some:jdk/src/hotspot/share/compiler/compilerDirectives.hpp
Lines 37 to 60 in 9f9e73d
But I couldn't recycle
compilerdirectives_common_flags(or similar) to define this mapping because the alias is just the default value. It can also be a literal. WhilePrintAssemblyis an alias forPrintAssembly,MemLimitis not an alias for0, it's just the default value. The best I could find is to assume that if there is a flag, it bears the same name. The only thing that looks like an exception isLogandLogCompilation, but actually, theCompileCommandLogrequires theLogCompilationflag (which is diagnostic) to be set. So it is not actually an alias.Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25150/head:pull/25150$ git checkout pull/25150Update a local copy of the PR:
$ git checkout pull/25150$ git pull https://git.openjdk.org/jdk.git pull/25150/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 25150View PR using the GUI difftool:
$ git pr show -t 25150Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25150.diff
Using Webrev
Link to Webrev Comment