Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 346653

Summary:	[xtext][refactoring] Error message is not very helpful
Product:	[Modeling] TMF	Reporter:	Sebastian Zarnekow <sebastian.zarnekow>
Component:	Xtext	Assignee:	Project Inbox <tmf.xtext-inbox>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	jan
Version:	2.0.0	Flags:	sebastian.zarnekow: indigo+
Target Milestone:	SR2
Hardware:	PC
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:
Bug Depends on:	327863, 356342
Bug Blocks:

Description Sebastian Zarnekow

2011-05-20 08:04:20 EDT

Grammar:

Model:
	greetings+=Greeting*;
	
Greeting:
	'Hello' name=ID '!' other=[Greeting]?;

File1:

Hello Greeting1! Greeting1

File2:

Hello Greeting2! Greeting1

Try to rename Greeting1 in File1 to Greeting2. You'll get a dialog with:

[
A fatal error occurred while performing the refactoring.

Found problems:
Error during refactoring: null argument. See log for details.

No context information available.
]

The error log does not contain any entries. Nothing in the log of the host-eclipse, too.

Comment 1 Jan Koehnlein

2011-08-31 10:34:27 EDT

Issue continued in bug 356342.

*** This bug has been marked as a duplicate of bug 356342 ***

Comment 2 Jan Koehnlein

2011-08-31 10:58:00 EDT

Not a duplicate, but a dependency.

Comment 3 Jan Koehnlein

2011-09-01 03:16:05 EDT

The problem here is that we have no strategy to check uniqueness of names cross resource boundries (see bug 327863).

When updating a cross reference to a renamed element, the cross reference serializer (CRS) is asked for the replacement text. If the renamed element is shadowed, this text is null, as the scope implementation filters it silently. 

From a user point of view, I'd expect an rename status warning in this case (as in JDT a "possible conflict"), but the refactoring should be forceable if I know what I am doing. 

As the filtering of shadowed elements is internal to the scope implementation, there is no way to access the filtered elements from the outside. That's a pity, as it gets almost impossible to get the link text for the "force" case described above. 

I see two options
1) Report a fatal error in the case the CrossRefSerializer returns null. Refactoring cannot be performed then, so there is no "force anyway" option.
2) Don't use the CrossRefSerializer to calculate the replace text but our own component with a fallback strategy: If the element cannot be found in the scope, report a warning and look it up in the parent scope recursively. The disadvantage is that a customized CRSs will be ignored. BTW, the Xtext grammar language has a customized CRS...

Comment 4 Jan Koehnlein

2011-09-01 09:56:44 EDT

Added a hook to resolve name conflicts in bug 345589.

Error dialog now show critical location.

Comment 5 Jan Koehnlein

2011-09-01 09:57:07 EDT

Pushed to MASTER

Comment 6 Karsten Thoms

2017-09-19 16:59:23 EDT

Closing all bugs that were set to RESOLVED before Neon.0

Comment 7 Karsten Thoms

2017-09-19 17:10:53 EDT

Closing all bugs that were set to RESOLVED before Neon.0