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

Bug 54431

Summary:	ASTParser should honor set compiler options in all cases
Product:	[Eclipse Project] JDT	Reporter:	Dirk Baeumer <dirk_baeumer>
Component:	Core	Assignee:	Olivier Thomann <Olivier_Thomann>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	jeem
Version:	3.0
Target Milestone:	3.0 M8
Hardware:	PC
OS:	Windows XP
Whiteboard:
Bug Depends on:
Bug Blocks:	52773

Description Dirk Baeumer

2004-03-11 04:48:34 EST

I20040310

Refactoring needs to parse compilation units without the nice extra style 
errors. To do so I used the new ASTParser and set it a modified version of the 
compiler options will all additional compiler settings turned to ignore. But 
the parser ignores these settings when parsing CUs (it always takes the 
settings from the project containing the CU). The parser should honor the set 
settings even in this case.

Comment 1 Olivier Thomann

2004-03-11 16:48:03 EST

I released the right code for ASTParse.create... method.
If you set the new compiler options using setCompilerOptions(...) after you set
the ICompilationUnit. It should do it.
I added TODOs for Jim to update the javadoc and explain that
setSource(ICompilationUnit) also sets the java project and the compiler options.
Give it a try and reopen it if your problem is not fixed.
All tests passed.

Comment 2 Dirk Baeumer

2004-03-22 06:00:45 EST

The ASTParser now correctly remembers the options set via setCompilerOptions, 
these options, but they are not passed to the CompilationUnitResolver.resolve 
method. Hence the resolver is again taking the options from the project.

See code CompilationUnitResolver#resolve and its use in 
ASTParser#internalCreateAST.

Comment 3 Olivier Thomann

2004-03-22 08:47:29 EST

I am investigating.

Comment 4 Olivier Thomann

2004-03-22 10:36:55 EST

Changed the code in CompilationUnitResolver to reuse the compiler options set in
the ASTParser.
Fixed and released in HEAD.
I will write a test case for this one.

Comment 5 Dirk Baeumer

2004-03-23 05:10:35 EST

Should the fix be in I200403230010 ?

Comment 6 Olivier Thomann

2004-03-23 09:06:45 EST

Yes. Do you have a problem with it?

Comment 7 Dirk Baeumer

2004-03-23 18:36:15 EST

No, just wanted to double check since I tested and earlier build.

Comment 8 Olivier Thomann

2004-03-24 10:33:47 EST

Dirk, could you please confirm that it is now working as desired and close as
VERIFIED?
Thanks.

Comment 9 Dirk Baeumer

2004-03-24 13:11:59 EST

Verified