Cleanup of deprecation handling

[stephan-herrmann]

Post-hoc summary of a "spring cleaning" of how JDT deals with deprecation.

This started out with @SuppressWarnings("deprecation") becoming unused

• reported in members of a deprecated type are not implicitly deprecated #4553
• caused by Do not emit restriction warning on inherited method #4293

Investigation of #4553 revealed that ecj has been reporting far too many deprecation warnings all the time:

• ecj considered all members of a deprecated type as "implicitly deprecated", which is incorrect wrt JLS
• this has been fixed via members of a deprecated type are not implicitly deprecated #4564
• the following changes were then made to avoid new warnings in our code
  • Remove @SuppressWarnings annotation no longer raised by ecj eclipse.jdt.debug#799
  • Remove @SuppressWarnings annotation no longer raised by ecj, take 2 eclipse.jdt.debug#800
  • Removed unnecessary @SuppressWarnings("deprecation") from jdt.ui eclipse.jdt.ui#2573

Next we observed, that JDT/UI would still show members as deprecated (strike-through) that according to the corrected concept aren't deprecated.

• fixed Adjust highlighting of deprecation eclipse.jdt.ui#2578
• additional case fixed in Highlight deprecation of canonical record constructor eclipse.jdt.ui#2582

Another bug was discovered regarding "friendly" code locations not getting the warning:

• reported in Not all deprecation warnings reported for types defined in one java file #4563
  • friendliness requires a common enclosing type, not just colocation in the same CU
• addressed in Not all deprecation warnings reported for types defined in one java file #4570

To support users in getting optimal visibility of deprecation despite #4564 a new compiler warning was proposed:

• filed as Option to inform about members of a deprecated type not being deprecated #4568
• implemented in Option to inform about members of a deprecated type not being deprecated #4569
• update in jdt.ui: Support new warning COMPILER_PB_MEMBER_OF_DEPRECATED_TYPE eclipse.jdt.ui#2587
  • surface the option in preferences UI
  • offer (multi-) quickfix

Found a situation where deprecation warnings are missing:

• Missing warning for use of deprecated annotation elements #4571
• Missing warning for use of deprecated annotation elements #4573

Also preferences controlling deprecation warnings seem to be evaluated inconsistently:

• Deprecation warnings incompletely controlled by compiler preferences #4562

Request for documentation

• Provide user documentation with the summary of changes in "deprecation" area #4576

[iloveeclipse]

@stephan-herrmann, there are following test failures that need correction because of changes made:

• org.eclipse.jdt.apt.tests.ReadAnnotationTests.test0 fails since I20251029-1800 #4577
• ModifierCorrectionsQuickFixTest1d7 & QuickFixTest1d8 fail since I20251029-1800 eclipse.jdt.ui#2588

[stephan-herrmann]

@stephan-herrmann, there are following test failures that need correction because of changes made:

Just in time 😄

Additionally, I saw more warnings reported in JDT/UI builds, most of which are due to #4569. I plan to address these using the new quickfix from eclipse-jdt/eclipse.jdt.ui#2587 i.e., add @Deprecated to members that previously where "implicitly deprecated" -- @iloveeclipse do you agree to this?

[iloveeclipse]

I plan to address these using the new quickfix from eclipse-jdt/eclipse.jdt.ui#2587 i.e., add @Deprecated to members that previously where "implicitly deprecated"

Woukd be great, yes.

[stephan-herrmann]

Documentation is online at https://eclipse.dev/eclipse/markdown/?f=news/4.38/jdt.md#changes-concerning-deprecation-warnings

Mail has been sent, e.g., https://www.eclipse.org/lists/eclipse-dev/msg12448.html

Closing.