Bugzilla – Full Text Bug Listing
| Summary: | [Refactoring] Filtering of Fragments in Refactoring may cause bogus things | ||
|---|---|---|---|
| Product: | [Modeling] TMF | Reporter: | Holger Schill <Holger.Schill> |
| Component: | Xtext | Assignee: | Project Inbox <tmf.xtext-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | jan, sven.efftinge |
| Version: | 2.2.0 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
Is this really used in refactoring? I could not find the location. I can only find it in find references, where it yields immediate UI results and can be debugged easily. I consider changing the fragment strategy for the inferred model quite harmful. IMHO, whoever changes the IFragmentProvider that way should also be able to adapt the JvmModelReferenceFilter. If anyone comes with a more resilient strategy to find out if the source of an indexed reference is an inferred model, we can of course take that. Maybe we can store this information in the IReferenceDecription. I am inclined to close this as WON'T FIX. Comments? agreed |
For a language that inherited Xbase and unses the Refactoring there might be a bogus behaviour when someone customised the FragmentProvider for whatever reason. The Method org.eclipse.xtext.xbase.ui.jvmmodel.findrefs.JvmModelReferenceFilter.isInferredJvmElement(URI) is called to filter out inferred JVMTypes during the refactoring. This is done by filter out fragments with a simple heuristic. !fragment.startsWith("/0") && !fragment.startsWith("//") && !fragment.equals("/") In some cases a custom Fragmentprovider may produce Fragments which does not pass this filter and so some elements are not refactored and the reason is not transparent enough. Maybe we should find another way of filtering.