Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 354536 - compiling package-info.java still depends on the order of compilation units
Summary: compiling package-info.java still depends on the order of compilation units
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.7   Edit
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: 3.7.1   Edit
Assignee: Stephan Herrmann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 355552 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-08-11 13:40 EDT by Stephan Herrmann CLA
Modified: 2011-09-13 11:46 EDT (History)
5 users (show)

See Also:
Olivier_Thomann: review+

Attachments
Testcase (2.08 KB, patch)
2011-08-11 13:43 EDT, Stephan Herrmann CLA 		no flags Details | Diff
Same test plus proposed fix (2.97 KB, patch)
2011-08-11 14:20 EDT, Stephan Herrmann CLA 		no flags Details | Diff
Same patch with copyright updated (4.28 KB, patch)
2011-08-12 16:25 EDT, Stephan Herrmann CLA 		no flags Details | Diff
Show Obsolete (2) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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.