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

Bug 106603

Summary:	[model] Rename Type still reports syntax error after switch to 5.0
Product:	[Eclipse Project] JDT	Reporter:	Markus Keller <markus.kell.r>
Component:	Core	Assignee:	JDT-Core-Inbox <jdt-core-inbox>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3
Version:	3.1
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:	stalebug

Description Markus Keller

2005-08-10 04:52:21 EDT

I20050808-2000, already in 3.1

- new 1.4 Java project
- new class C
- in editor, add type parameter <E> to C
- quick fix to switch project to 5.0 (or change manually in project properties)
=> syntax errors disappear in editor and Package Explorer
- select 'C' in declaration 'class C<E>'
- Refactor > Rename
=> dialog box appears and says that the refactoring cannot be performed due to
syntax errors

Comment 1 Dirk Baeumer

2005-08-11 11:23:56 EDT

Markus, can you please have a look ?

Comment 2 Markus Keller

2005-08-22 13:46:44 EDT

Moving to JDT/Core for comments.

Before starting the refactoring, we ask ICompilationUnit#isStructureKnown()
(in Checks.checkIfCuBroken(..)).
Expected: true
Was: false

Interestingly, if you ask IType#isStructureKnown() on type C, you get true at
that time. I checked that the reconcile passed, so I think this is a JDT/Core
problem.

Comment 3 Jerome Lanneluc

2005-08-24 06:34:17 EDT

Since there was no change in the source, the second reconcile doesn't re-parse
the cu, thus it still thinks it has syntax errors (and its structure is not known).

Need to find a way to detect this case ...

Note that any element inside an ICompilationUnit will always return true to
isStructureKnown(). This is debatable.

Comment 4 Jerome Lanneluc

2007-06-22 06:47:27 EDT

We could store the source level used during the last reconcile in the ASTHolderCUInfo and compare it to the current one. If they are different, and even if the source has not changed, then we would force the reconcile.

Comment 5 Markus Keller

2007-06-22 08:37:52 EDT

(In reply to comment #4)
How does this work if I change other compiler options (like enabling a new warning)? Shouldn't the same mechanism also make the working copy dirty when the source level changes?

Comment 6 Jerome Lanneluc

2007-06-22 09:06:51 EDT

Hum, you're right. So we should listen for preferences change and mark the corresponding working copies as not consistent when any compiler options change.

Comment 7 Jerome Lanneluc

2008-03-26 12:50:46 EDT

See also bug 223910

Comment 8 Jerome Lanneluc

2008-05-12 05:31:03 EDT

Deferring post 3.4

Comment 9 Jerome Lanneluc

2008-09-11 11:13:03 EDT

Targeting M5

Comment 10 Jerome Lanneluc

2009-01-09 05:17:55 EST

Not for 3.5

Comment 11 Eclipse Genie

2019-07-17 13:02:12 EDT

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.

If you have further information on the current state of the bug, please add it. 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.