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

Bug 354536

Summary: compiling package-info.java still depends on the order of compilation units
Product: [Eclipse Project] JDT Reporter: Stephan Herrmann <stephan.herrmann>
Component: CoreAssignee: Stephan Herrmann <stephan.herrmann>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: amj87.iitr, jarthana, martin.von.zweigbergk, Olivier_Thomann, srikanth_sankaran
Version: 3.7Flags: Olivier_Thomann: review+
Target Milestone: 3.7.1   
Hardware: Other   
OS: Linux   
Whiteboard:
Attachments:
Description Flags
Testcase
none
Same test plus proposed fix
none
Same patch with copyright updated none

Description Stephan Herrmann CLA 2011-08-11 13:40:12 EDT 
This is similar to bug 322789 but still active:

I have a test case where I pass three compilation units to the compiler:

  p1/X.java: a class with an inner class "Inner"

  p1/package-info.java: marks this package as @Deprecated

  p2/C.java: should see X and everything inside as deprecated


I can toggle success/failure of this testcase by changing the order of
compilation units: passing package-info before X works, the order listed
above does not work, i.e., deprecation is not reported.

Could this be an artifact of the InMemoryNameEnvironment used by the
tests? Otherwise I'd consider checking type deprecation later in the
process, if possible.

The relevant call chain is the same as in bug 322789 comment 17.
Comment 1 Stephan Herrmann CLA 2011-08-11 13:43:09 EDT 
Created attachment 201338 [details]
Testcase

Here's the failing test case.
Comment 2 Stephan Herrmann CLA 2011-08-11 14:20:28 EDT 
Created attachment 201340 [details]
Same test plus proposed fix

This looks sweet: simply deleting two lines seems to solve the issue:

ClassScope.checkAndSetModifiers() should not call isViewedAsDeprecated()
for member types, because this call originating from 
Compiler.beginToCompile() is way too early for requesting another type 
(here package-info.java).

This call appears to be unnecessary, too: the same effect is also achieved
later when ASTNode.isTypeUseDeprecated() calls
refType.initializeDeprecatedAnnotationTagBits()

The other calls inside ClassScope.checkAndSetModifiers() are OK because
they only happen later, like during resolve.

I'm currently running test against the patch.
Comment 3 Stephan Herrmann CLA 2011-08-12 16:25:26 EDT 
Created attachment 201432 [details]
Same patch with copyright updated

All compiler and model tests passed with this patch.
Comment 4 Stephan Herrmann CLA 2011-08-12 16:41:21 EDT 
Released in HEAD for 3.8M2.
Comment 5 Olivier Thomann CLA 2011-08-23 17:44:39 EDT 
+1 for this fix in case we want to also release it for 3.7.1 (in order to fix the issue reported in bug 348024).
Comment 6 Srikanth Sankaran CLA 2011-08-24 01:02:03 EDT 
*** Bug 355552 has been marked as a duplicate of this bug. ***
Comment 7 Srikanth Sankaran CLA 2011-08-24 02:18:10 EDT 
(In reply to comment #5)
> +1 for this fix in case we want to also release it for 3.7.1 (in order to fix
> the issue reported in bug 348024).

+1 for 3.7.1, Jay, please take this forward for 3.7.1
Comment 8 Srikanth Sankaran CLA 2011-08-24 02:39:38 EDT 
Released in 3.7.x maintenance branch for 3.7.1 RC2.
Jay, please include fix for RC2 -- Thanks.
Comment 9 Jay Arthanareeswaran CLA 2011-08-25 06:13:01 EDT 
Verified for 3.7.1 RC2 with build M20110824-0800.
Comment 10 Olivier Thomann CLA 2011-09-13 11:46:27 EDT 
Verified for 3.8M2.