This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 170574 - [68cat] "Assign Return Value To New Variable" doesn't infer wildcard bound when it could
Summary: [68cat] "Assign Return Value To New Variable" doesn't infer wildcard bound wh...
Status: RESOLVED DUPLICATE of bug 258167
Alias: None
Product: java
Classification: Unclassified
Component: Hints (show other bugs)
Version: 6.x
Hardware: PC Windows XP
: P3 blocker (vote)
Assignee: Svata Dedic
URL:
Keywords:
Depends on: 262073
Blocks:
  Show dependency tree
 
Reported: 2009-08-18 19:19 UTC by matthies
Modified: 2016-05-17 08:45 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description matthies 2009-08-18 19:19:22 UTC 
Example:

    interface Foo<T>
    {
        Foo<? extends T> foo();
    }

    Foo<? extends Number> bar = null;
    bar.foo();

The result of "Assign Return Value To New Variable" on "bar.foo()" is:

    Foo<? extends <captured wildcard>> foo = bar.foo();

But it could have inferred this:

    Foo<? extends Number> foo = bar.foo();

An upper bound of an uppber bound is still an upper bound.

Same for lower bounds:

    interface Foo<T>
    {
        Foo<? super T> foo();
    }

    Foo<? super Number> bar = null;
    Foo<? super Number> foo = bar.foo();
Comment 1 Max Sauer 2009-08-21 11:48:02 UTC 
Fixed. Please verify.
---
http://hg.netbeans.org/jet-main/rev/b2a893c02800
Comment 2 Quality Engineering 2009-08-25 02:43:38 UTC 
Integrated into 'main-golden', will be available in build *200908242212* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/b2a893c02800
User: Max Sauer <msauer@netbeans.org>
Log: #170574: "Assign Return Value To New Variable" doesnt infer wildcard bound when it could
Comment 3 matthies 2009-10-27 21:11:11 UTC 
It's fixed for the two spefic examples I gave, but it's not fixed for the general case, and also new errors have been 
introduced.

For example this case remains unfixed:

    interface Foo<T>
    {
        Foo<? extends ThreadLocal<? extends T>> foo();
    }

    Foo<? extends Number> bar = null;
    bar.foo();

This results in:

    Foo<? extends ThreadLocal<? extends <captured wildcard>>> foo = bar.foo();

The correct result would be:

    Foo<? extends ThreadLocal<? extends Number>> foo = bar.foo();


Combinations of upper and lower bounds now result in erroneous completions. Examples:

    interface Foo<T>
    {
        Foo<? super T> foo();
    }

    Foo<? extends Number> bar = null;
    bar.foo();

This results in:

    Foo<? extends Number> foo = bar.foo();

Which is faulty because no bound can be inferred (it's effectively "? super ? extends Number"), so the only sensible 
completion would be:

    Foo<?> foo = bar.foo();

Likewise, 

    interface Foo<T>
    {
        Foo<? extends T> foo();
    }

    Foo<? super Number> bar = null;
    bar.foo();

results in the faulty

    Foo<? super Number> foo = bar.foo();

instead of in

    Foo<?> foo = bar.foo();

To combine these,

    interface Foo<T>
    {
        Foo<? extends ThreadLocal<? extends T>> foo();
    }

    Foo<? super Number> bar = null;
    bar.foo();

results in

    Foo<? extends ThreadLocal<? extends <captured wildcard>>> foo = bar.foo();

but should result in

    Foo<? extends ThreadLocal<?>> foo = bar.foo();

Also,

    interface Foo<T extends Number>
    {
        Foo<? extends T> foo();
    }

    Foo<? super Long> bar = null;
    bar.foo();

results in the faulty

    Foo<? super Long> foo = bar.foo();

but should result in

    Foo<? extends Number> foo = bar.foo();

Likewise,

    interface Foo<T extends Number>
    {
        Foo<? extends Foo<? extends T>> foo();
    }

    Foo<? super Long> bar = null;
    bar.foo();

should result in

    Foo<? extends Foo<? extends Number>> foo = bar.foo();

And so on.
Comment 4 Marian Mirilovic 2012-10-19 16:30:56 UTC 
yes, cases from comment 3 do not work in NB 7.2.1 ... and calling hint causes exception - see issue 206536
Comment 5 Svata Dedic 2016-05-16 14:10:49 UTC 
except the last case will be solved as part of #258167. Thanks for the testcases and sorry the fix took so long :(

*** This bug has been marked as a duplicate of bug 258167 ***