| Summary: | NullPointerException in EObjectAtOffsetHelper | ||
|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Michael Clay <clay> |
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | kimi_anwen, knut.wannheden, stephan.herrmann, sven.efftinge |
| Version: | 2.0.0 | Flags: | sven.efftinge:
indigo+
|
| Target Milestone: | SR2 | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
| Bug Depends on: | 347284 | ||
| Bug Blocks: | |||
|
Description
Michael Clay
added missing null guard and test -> pushed to master Shouldn't the EObjectAtOffsetHelper instead of returning null try to resolve the previous token if the offset is at the end of the document? This is of course also related to bug 347284. tbd see bug 347284 *** Bug 350708 has been marked as a duplicate of this bug. *** I have the same problem. I use the method in my character pair matcher, and using the EObjectAtOffsetHelper.resolveElementAt() method. However, when clicking at the end of the file and got errors syntax , and I get the NPE at the same stack trace. Target Milestone = SR2? This would mean that for DSLs affected by this bug mark occurrences should be turned off until next year? That'd be a pity. SR2 is the flag we use for the 2.1 release which is planned for mid October. (In reply to comment #7) > SR2 is the flag we use for the 2.1 release which is planned for mid October. ups, seems I misinterpreted SR1 to mean Indigo SR1 :) Thanks for clarification, that's good news actually! Closing this since the NPW has been handled and the outstanding issue is covered in Bug #347284 |