Community
Participate
Working Groups
Build 3.2m5 On following testcase, #bar() is not offered as a possible completion. If assisting right after the '#', then only Object methods are proposed. public class X { /** * @see p.A#b<CODEASSIST HERE> */ void foo() { } } ================== package p; /** @deprecated */ public class A { void bar() {} }
Javadoc may warn deprecated references in a different way than in java code, see specific JavaCore compiler options for this: COMPILER_PB_INVALID_JAVADOC COMPILER_PB_INVALID_JAVADOC_TAGS COMPILER_PB_INVALID_JAVADOC_TAGS_VISIBILITY COMPILER_PB_INVALID_JAVADOC_TAGS__DEPRECATED_REF So, if we want to take this option into account, AssistOption should have another fields to keep these options available and modify all code where checkDeprecation field is called in CompletionEngine. One say that we can also forget this filter in Javadoc comments and propose even deprecated references, but IMO we should avoid to insert something flagged as warning... David, what is your mind about this?
The options of code assist are not linked to compiler options. If the filtering of deprecated elements is enabled in code assist then deprecated references are filtered even if deprecated references are not reported as problem. Moreover deprecation filtering is disabled by default. Link code assist and compiler options could be a good idea, but if we do that we must do it for all code assist options to not disturb users. For the specific test case of this bug report the problem isn't deprecation. The method isn't proposed because bar() isn't visible and by default codeassist filter non visible methods. This could be change with Preferences>Java>Editor>Content Assist>Hide proposals not visible in the invocation context option. Closed as INVALID
