8257037: No javac warning when calling deprecated constructor with diamond #1490

lgxbslgx · 2020-11-28T09:46:06Z

Hi all,

When calling deprecated constructor with diamond, the compiler doesn't output warning.
The test case is shown below.

GenericClass<Object> o2 = new GenericClass<>();

public class GenericClass<T> {
    @Deprecated
    public GenericClass() {}
}

This patch solves the bug and adds corresponding test case.
Thank you for taking the time to review.

Best Regards.

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8257037: No javac warning when calling deprecated constructor with diamond

Reviewers

Maurizio Cimadamore (@mcimadamore - Reviewer)

Download

$ git fetch https://git.openjdk.java.net/jdk pull/1490/head:pull/1490
$ git checkout pull/1490

…amond

bridgekeeper · 2020-11-28T09:46:54Z

👋 Welcome back lgxbslgx! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2020-11-28T09:47:56Z

@lgxbslgx The following label will be automatically applied to this pull request:

compiler

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.

mlbridge · 2020-11-28T09:51:07Z

Webrevs

lgxbslgx · 2020-11-28T11:43:06Z

Sorry for closing the PR accidentally.

mcimadamore

I think the fix seems in spirit with respect to what happens for ordinary constructor resolution. I guess there is a question as to whether we should check for these warnings during resolution or after (probably checking for warning after resolution might be a better idea) - as there is some duplication between the code in findConstructor and the new findDiamond and what goes on in Attr::checkId which also check for these warnings (and some more) but doesn't apply checks on constructors.

Just for fun, I tried this patch:

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
index df21524229c..05d56136000 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
@@ -4459,15 +4459,11 @@ public class Attr extends JCTree.Visitor {
             }
 
             // Emit a `deprecation' warning if symbol is deprecated.
-            // (for constructors (but not for constructor references), the error
-            // was given when the constructor was resolved)
 
-            if (sym.name != names.init || tree.hasTag(REFERENCE)) {
-                chk.checkDeprecated(tree.pos(), env.info.scope.owner, sym);
-                chk.checkSunAPI(tree.pos(), sym);
-                chk.checkProfile(tree.pos(), sym);
-                chk.checkPreview(tree.pos(), sym);
-            }
+            chk.checkDeprecated(tree.pos(), env.info.scope.owner, sym);
+            chk.checkSunAPI(tree.pos(), sym);
+            chk.checkProfile(tree.pos(), sym);
+            chk.checkPreview(tree.pos(), sym);
 
             // If symbol is a variable, check that its type and
             // kind are compatible with the prototype and protokind.
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
index 727d2989adf..9bb37fc23b8 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
@@ -2859,8 +2859,6 @@ public class Resolve {
                                     names.init, argtypes,
                                     typeargtypes, allowBoxing,
                                     useVarargs);
-        chk.checkDeprecated(pos, env.info.scope.owner, sym);
-        chk.checkPreview(pos, sym);
         return sym;
     }
 
@@ -2937,6 +2935,7 @@ public class Resolve {
                             return sym;
                         }
                     };
+                    newConstr.setAttributes(sym);
                     bestSoFar = selectBest(env, site, argtypes, typeargtypes,
                             newConstr,
                             bestSoFar,

This fixes your issues, and removes the warning code duplication between Attr and Resolve, as well as adding checks for all the remaining kinds of warnings (sunAPI, deprecation, preview and profile) - although I believe most of those are not as important.

I guess I'll leave you to decide how you want to tackle this. As I said, the patch you wrote remains within the spirit of the original code - my only minor quibble is that this "spirit" is questionable, as it involves issuing same warnings in different places, this enforcing developers to replicate code (and forgetting to do so, as it already happened) in multiple places.

lgxbslgx · 2020-11-30T16:00:42Z

Thank you for the comment and suggestion.

I had seen and paid attention to the following code in Attr.java when being solved this bug.

            // (for constructors (but not for constructor references), the error
            // was given when the constructor was resolved)

            if (sym.name != names.init || tree.hasTag(REFERENCE)) {
                chk.checkDeprecated(tree.pos(), env.info.scope.owner, sym);
                chk.checkSunAPI(tree.pos(), sym);
                chk.checkProfile(tree.pos(), sym);
                chk.checkPreview(tree.pos(), sym);
            }

These code confused me. Because the comments (for constructors, the error was given when the constructor was resolved) and the conditional expression sym.name != names.init were submitted at 2007(submit log: Initial load). And nobody raises suggestion to it over these years though this code snippet had been revised many times.

In order not to generate unknown issues, I chose not to revise these code when being solved this bug.

@mcimadamore I test your patch locally by using the following command. All the tests passed.

make test TEST="jtreg:langtools/tools/javac" CONF=linux-x86_64-server-release

Your patch is a better solution if no any unknown regression occurs. But I have no idea about the unknown regressions now.
I would like to accept your suggestion and revise my code. And we should think more situations which could generate regressions to avoid unknown issues occur.

Finally, I have a little question.
Is the code newConstr.setAttributes(sym); necessary in Resolve.findDiamond?
I delete it in your patch, and test locally by using the following command. All the tests passed.

make test TEST="jtreg:langtools/tools/javac" CONF=linux-x86_64-server-release

…he redundant warning code

mcimadamore · 2020-12-01T21:08:15Z

Is the code newConstr.setAttributes(sym); necessary in Resolve.findDiamond?

Sorry, that was a leftover from a previous experiment. That's not necessary. We'll run some more tests on our side and I'll let you know.

lgxbslgx · 2020-12-02T07:30:08Z

@mcimadamore Should I add you as a contributor of this patch? Does it need another reviewer to review if I add you as a contributor?

mcimadamore · 2020-12-02T12:15:08Z

@mcimadamore Should I add you as a contributor of this patch? Does it need another reviewer to review if I add you as a contributor?

As you prefer - I don't mind either way. I don't think adding me as a contributor should prevent the integration, or me being able to sponsor, but I'm not 100% sure.

lgxbslgx · 2020-12-02T13:08:21Z

/contributor add @mcimadamore

openjdk · 2020-12-02T13:08:48Z

@lgxbslgx
Contributor Maurizio Cimadamore <mcimadamore@openjdk.org> successfully added.

lgxbslgx · 2020-12-04T19:11:01Z

I revise the test code based on the comment[1] written by Jonathan Gibbons in JDK-8231622[2].

For tests that use /ref=file -XDrawDiagnostics the conventions are:

Omit the complete legal header, including the copyright and license

After @test add the text /nodynamiccopyright/

#1 protects the file against any future changes in the length of the legal header, that might affect line numbers, and #2 is for use by automated scripts that may check for the presence of the legal header.

[1] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015542.html
[2] #1626

mcimadamore · 2020-12-07T10:40:05Z

The extensive testing revealed at least 10 cases where the compiler is issuing a new, resolution-related error when it wasn't doing so before - (the errors seem to have to do with abstract methods). As a result I think it's best to go with your first conservative approach, to avoid troubles. I'll try to investigate further and come up with a reduced test case for the failing condition - but that doesn't have to hold up this fix. Thanks!

lgxbslgx · 2020-12-07T11:54:08Z

It is a good news that the trouble is found before the integration instead of after the release of JDK16.
I revise the code to previous version.
Thank your for the review.

openjdk · 2020-12-07T11:54:30Z

@lgxbslgx Syntax: /contributor (add|remove) [@user | openjdk-user | Full Name <email@address>]. For example:

/contributor add @openjdk-bot
/contributor add duke
/contributor add J. Duke <duke@openjdk.org>

lgxbslgx · 2020-12-07T11:54:49Z

/contributor remove @mcimadamore

openjdk · 2020-12-07T11:55:04Z

@lgxbslgx
Contributor Maurizio Cimadamore <mcimadamore@openjdk.org> successfully removed.

mcimadamore · 2020-12-07T12:15:18Z

Actually, after some more analysis, I discovered that many of the errors were unrelated with your fix - and had to do instead with the addition of a new default method on Stream, which is causing overload resolution changes in code that has static imports on Collectors.

Only one issue remains to be fully triaged - but, being annotation related, I think it's unlikely caused by your patch. In other words, I believe both patches are likely to be safe. I'm obviously ok with you going ahead with the more conservative fix, since you already reverted the code to that version.

I apologize for the back and forth!

mcimadamore

Looks good to go

openjdk · 2020-12-07T12:16:05Z

@lgxbslgx 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:

8257037: No javac warning when calling deprecated constructor with diamond

Reviewed-by: mcimadamore

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 151 new commits pushed to the master branch:

637b0c6: 8246778: Compiler implementation for Sealed Classes (Second Preview)
09707dd: 8252807: The jdk.jfr.Recording.getStream does not work when toDisk is disabled
04ce8e3: 8257184: Upstream 8252504: Add a method to MemoryLayout which returns a offset-computing method handle
5a03e47: 8255560: Class::isRecord should check that the current class is final and not abstract
8e8e584: 8257588: Make os::_page_sizes a bitmask
566d77a: 8254802: ThrowingPushPromisesAsStringCustom.java fails in "try throwing in GET_BODY"
f5a582c: 8257575: C2: "failed: only phis" assert failure in loop strip mining verification
d05401d: 8256679: Update serialization javadoc once JOSS changes for records are complete
7620124: 8257230: assert(InitialHeapSize >= MinHeapSize) failed: Ergonomics decided on incompatible initial and minimum heap sizes
05dac03: 8257803: Add -Xbatch to compiler/blackhole tests
... and 141 more: https://git.openjdk.java.net/jdk/compare/1241f800023996d33b39a2b881b2bf7e3b7201c3...master

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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@mcimadamore) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

lgxbslgx · 2020-12-07T12:41:44Z

/integrate

openjdk · 2020-12-07T12:42:20Z

@lgxbslgx
Your change (at version c4de5fa) is now ready to be sponsored by a Committer.

mlbridge · 2020-12-07T12:46:19Z

Mailing list message from Remi Forax on compiler-dev:

oops,
you mean Collectors.toList() vs Stream.toList()

R?mi

----- Mail original -----

De: "Maurizio Cimadamore" <mcimadamore at openjdk.java.net>
?: "compiler-dev" <compiler-dev at openjdk.java.net>
Envoy?: Lundi 7 D?cembre 2020 13:18:16
Objet: Re: RFR: 8257037: No javac warning when calling deprecated constructor with diamond [v2]

mcimadamore · 2020-12-07T13:49:12Z

you mean Collectors.toList() vs Stream.toList()

yes - precisely

mcimadamore · 2020-12-07T13:49:19Z

/sponsor

openjdk · 2020-12-07T13:49:25Z

@mcimadamore Only the author (@lgxbslgx) is allowed to issue the integrate command. As this PR is ready to be sponsored, and you are an eligible sponsor, did you mean to issue the /sponsor command?

mcimadamore · 2020-12-07T13:50:50Z

/sponsor

openjdk · 2020-12-07T13:51:47Z

@mcimadamore @lgxbslgx Since your change was applied there have been 154 commits pushed to the master branch:

46b35ac: 8257798: [PPC64] undefined reference to Klass::vtable_start_offset()
ecd7e47: 8257793: Shenandoah: SATB barrier should only filter out already strongly marked oops
e08b9ed: 8257820: Remove gc/ergonomics/TestMinHeapSize.java as it is too brittle
637b0c6: 8246778: Compiler implementation for Sealed Classes (Second Preview)
09707dd: 8252807: The jdk.jfr.Recording.getStream does not work when toDisk is disabled
04ce8e3: 8257184: Upstream 8252504: Add a method to MemoryLayout which returns a offset-computing method handle
5a03e47: 8255560: Class::isRecord should check that the current class is final and not abstract
8e8e584: 8257588: Make os::_page_sizes a bitmask
566d77a: 8254802: ThrowingPushPromisesAsStringCustom.java fails in "try throwing in GET_BODY"
f5a582c: 8257575: C2: "failed: only phis" assert failure in loop strip mining verification
... and 144 more: https://git.openjdk.java.net/jdk/compare/1241f800023996d33b39a2b881b2bf7e3b7201c3...master

Your commit was automatically rebased without conflicts.

Pushed as commit 2c04fc0.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

8257037: No javac warning when calling deprecated constructor with di…

1ceb999

…amond

openjdk bot added the rfr Pull request is ready for review label Nov 28, 2020

openjdk bot added the compiler compiler-dev@openjdk.org label Nov 28, 2020

lgxbslgx closed this Nov 28, 2020

lgxbslgx deleted the 8257037 branch November 28, 2020 10:52

lgxbslgx restored the 8257037 branch November 28, 2020 11:00

Polish

1d2a73c

lgxbslgx reopened this Nov 28, 2020

mcimadamore reviewed Nov 30, 2020

View reviewed changes

Check @deprecated annotation in method Attr.checkIdInternal. Remove t…

66671b0

…he redundant warning code

Revise test. Remove legal header and add /nodynamiccopyright/.

1d06ad1

Fall back to the previos version.

c4de5fa

mcimadamore approved these changes Dec 7, 2020

View reviewed changes

openjdk bot added the ready Pull request is ready to be integrated label Dec 7, 2020

openjdk bot added the sponsor Pull request is ready to be sponsored label Dec 7, 2020

openjdk bot closed this Dec 7, 2020

openjdk bot added integrated Pull request has been integrated and removed sponsor Pull request is ready to be sponsored ready Pull request is ready to be integrated rfr Pull request is ready for review labels Dec 7, 2020

lgxbslgx deleted the 8257037 branch December 7, 2020 18:00

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

8257037: No javac warning when calling deprecated constructor with diamond #1490

8257037: No javac warning when calling deprecated constructor with diamond #1490

lgxbslgx commented Nov 28, 2020 •

edited by openjdk bot

Loading

bridgekeeper bot commented Nov 28, 2020

openjdk bot commented Nov 28, 2020

mlbridge bot commented Nov 28, 2020 •

edited

Loading

lgxbslgx commented Nov 28, 2020

mcimadamore left a comment

lgxbslgx commented Nov 30, 2020

mcimadamore commented Dec 1, 2020

lgxbslgx commented Dec 2, 2020 •

edited

Loading

mcimadamore commented Dec 2, 2020

lgxbslgx commented Dec 2, 2020

openjdk bot commented Dec 2, 2020

lgxbslgx commented Dec 4, 2020

mcimadamore commented Dec 7, 2020

lgxbslgx commented Dec 7, 2020 •

edited

Loading

openjdk bot commented Dec 7, 2020

lgxbslgx commented Dec 7, 2020

openjdk bot commented Dec 7, 2020

mcimadamore commented Dec 7, 2020

mcimadamore left a comment

openjdk bot commented Dec 7, 2020 •

edited

Loading

lgxbslgx commented Dec 7, 2020

openjdk bot commented Dec 7, 2020

mlbridge bot commented Dec 7, 2020

mcimadamore commented Dec 7, 2020

mcimadamore commented Dec 7, 2020 •

edited

Loading

openjdk bot commented Dec 7, 2020

mcimadamore commented Dec 7, 2020

openjdk bot commented Dec 7, 2020

8257037: No javac warning when calling deprecated constructor with diamond #1490

8257037: No javac warning when calling deprecated constructor with diamond #1490

Conversation

lgxbslgx commented Nov 28, 2020 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Download

bridgekeeper bot commented Nov 28, 2020

openjdk bot commented Nov 28, 2020

mlbridge bot commented Nov 28, 2020 • edited Loading

Webrevs

lgxbslgx commented Nov 28, 2020

mcimadamore left a comment

Choose a reason for hiding this comment

lgxbslgx commented Nov 30, 2020

mcimadamore commented Dec 1, 2020

lgxbslgx commented Dec 2, 2020 • edited Loading

mcimadamore commented Dec 2, 2020

lgxbslgx commented Dec 2, 2020

openjdk bot commented Dec 2, 2020

lgxbslgx commented Dec 4, 2020

mcimadamore commented Dec 7, 2020

lgxbslgx commented Dec 7, 2020 • edited Loading

openjdk bot commented Dec 7, 2020

lgxbslgx commented Dec 7, 2020

openjdk bot commented Dec 7, 2020

mcimadamore commented Dec 7, 2020

mcimadamore left a comment

Choose a reason for hiding this comment

openjdk bot commented Dec 7, 2020 • edited Loading

lgxbslgx commented Dec 7, 2020

openjdk bot commented Dec 7, 2020

mlbridge bot commented Dec 7, 2020

mcimadamore commented Dec 7, 2020

mcimadamore commented Dec 7, 2020 • edited Loading

openjdk bot commented Dec 7, 2020

mcimadamore commented Dec 7, 2020

openjdk bot commented Dec 7, 2020

lgxbslgx commented Nov 28, 2020 •

edited by openjdk bot

Loading

mlbridge bot commented Nov 28, 2020 •

edited

Loading

lgxbslgx commented Dec 2, 2020 •

edited

Loading

lgxbslgx commented Dec 7, 2020 •

edited

Loading

openjdk bot commented Dec 7, 2020 •

edited

Loading

mcimadamore commented Dec 7, 2020 •

edited

Loading