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.
| Summary: | [68cat] "Assign Return Value To New Variable" doesn't infer wildcard bound when it could | ||
|---|---|---|---|
| Product: | java | Reporter: | matthies <matthies> |
| Component: | Hints | Assignee: | Svata Dedic <sdedic> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | blocker | CC: | mmirilovic |
| Priority: | P3 | ||
| Version: | 6.x | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Issue Type: | DEFECT | Exception Reporter: | |
| Bug Depends on: | 262073 | ||
| Bug Blocks: | |||
Fixed. Please verify. --- http://hg.netbeans.org/jet-main/rev/b2a893c02800 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 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.
yes, cases from comment 3 do not work in NB 7.2.1 ... and calling hint causes exception - see issue 206536 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 *** |
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();