Bugzilla – Full Text Bug Listing
| Summary: | Bindings are null inside lambda whose type cannot be determined | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Carmi Grushko <carmi> | ||||
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | stephan.herrmann | ||||
| Version: | 4.7 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
From 15.27.2. Lambda Body,
Unlike code appearing in anonymous class declarations, the meaning of names and the this and super keywords appearing in a lambda body, along with the accessibility of referenced declarations, are the same as in the surrounding context
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. JLS defines rules for a valid Java program, but it does not define how to interpret the body of an unresolvable lambda expression. The latter is the realm of binding recovery which totally works as a "best-effort", hence not a bug. I s.o. is willing to provide a patch to improve binding recovery this could be re-opened as an enhancement. |
Created attachment 267926 [details] Repro test case for StandAloneASTParserTest In class Foo { static class UnsupportedException { } void foo() { BlaBla a = o -> new UnsupportedException(); } } The `UnsupportedException` in `new UnsupportedException` doesn’t resolve, even though the JLS mandates that `UnsupportedException` should have the same meaning outside of the lambda as inside, regardless of the type of the lambda. Verified that this happens at HEAD. To emphasize, I'm interested in getting as many bindings as possible under conditions of missing imports. In other words, I'm specifically interested in the case above, where the type of the lambda cannot be determined.