-
Notifications
You must be signed in to change notification settings - Fork 6.2k
8350584: Check the usage of LOG_PLEASE #23764
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 syan! A progress list of the required criteria for merging this PR into |
|
@sendaoYan 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 82 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 |
|
@sendaoYan 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. |
|
Having debug logging enabled in some tests is not necessarily an issue that needs to be "fixed". You need to ask the person who enabled it why they did so. If it is enabled in some tests then we do need to guard against redefinition incase it is globally enabled (and there is nothing wrong with that either). |
|
I don't understand how the redefinition error could be resolved. ?? |
Sorry, I forgot pass |
@tstuefe @rkennke Hi, Does the |
That. Yes, these are mine. I tend to introduce them when I think I may have to look at a failing gtest again, possibly on some weird platform. If people are bothered by it, we can remove the output, but I think they are still slightly useful in their current form. I never actually thought people would globally define the log. Using UL logging may not work as intended since UL may not be available in some gtests. While debug output is not bad, it's better to disable it by default, since we need to take care that the output does not overflow and get truncated by the jtreg runner. |
tstuefe
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.
This is fine.
|
Thanks all for the reviews. /integrate |
|
Going to push as commit b054d24.
Your commit was automatically rebased without conflicts. |
|
@sendaoYan Pushed as commit b054d24. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Hi all,
Seen discussion in #23290 (comment). The LOG_PLEASE macro seems currently being defined are debugging leftovers that shouldn't have been committed. It's definition is typically
commented or uncommented to provide some additional logging for some tests of interest.
This PR comment out the
#define LOG_PLEASEsame to other gtests. Change has been verified locally, test-fix only, no risk.Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23764/head:pull/23764$ git checkout pull/23764Update a local copy of the PR:
$ git checkout pull/23764$ git pull https://git.openjdk.org/jdk.git pull/23764/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 23764View PR using the GUI difftool:
$ git pr show -t 23764Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23764.diff
Using Webrev
Link to Webrev Comment