Bugzilla – Full Text Bug Listing
| Summary: | NPE working with array initializer | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] JSDT | Reporter: | Benjamin Reed <ranger> | ||||
| Component: | General | Assignee: | Nitin Dahyabhai <thatnitind> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Nitin Dahyabhai <thatnitind> | ||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | cbridgha, cmjaun, david_williams, nsand.dev | ||||
| Version: | 3.2.3 | Flags: | david_williams:
pmc_approved+
thatnitind: pmc_approved? (raghunathan.srinivasan) thatnitind: pmc_approved? (naci.dai) thatnitind: pmc_approved? (deboer) thatnitind: pmc_approved? (neil.hauge) thatnitind: pmc_approved? (kaloyan) cbridgha: pmc_approved+ cmjaun: review+ |
||||
| Target Milestone: | 3.2.4 | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | PMC_approved | ||||||
| Attachments: |
|
||||||
|
Description
Benjamin Reed
Seems to be triggered by a conditional expression : (((typeof e.labelSeparator) == "undefined") ? this.labelSeparator : e.labelSeparator) on this condition: ((typeof e.labelSeparator) == "undefined") Created attachment 193770 [details]
proposed patch
When resolving the types (and assigning the optimized constants) for array contents, failure to resolve a type for one of the initial contents results in the remainder not even trying to complete resolution. This leads to the NPE later on.
*Explain why you believe this is a stop-ship defect. Errors when running a builder can prevent the project from being marked as "built" by that builder. It may be triggered repeatedly on resource changes only to then keep failing. *Is there a work-around? Only by placing the troublesome file in a library instead of a source folder, but we don' get to dictate that to our users. *How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? Ad-hoc tested. *Give a brief technical overview. Who has reviewed this fix? When performing the analysis step for an ArrayInitializer, it expects the constant values have all already been computed by the previous resolve step of compilation. A but in the ArrayInitializer class prevented it from iterating through all of the array contents if one element didn't resolve its type as expected, the resolution step also being expected to have determined whether that element is or is not a constant. The later elements in the array then aren't resolved nor have their constant values determined at all. Chris has reviewed the change. *What is the risk associated with this fix? Low. The looping algorithm is calling other methods on the elements to have them do work. Returning from the method early in the loop when the loop's purpose isn't to "find" a particular element or value is a pretty clear mistake. looks good - I assume Not returning null won't change any caller's behavior. Released. |