Unwanted PostHighlightingPass, how to disable unused reference checking?

Hello Scott,

PostHighlightingPass checks only references inside elements that implement
PsiIdentifier. Typically, there should be no need to implement PsiIdentifier
in a non-Java language.

Alternatively, if you don't want to change your class structure, you can
implement ImplicitUsageProvider to make IDEA consider all of your references
implicitly used.

Hi.  IntelliJ's builtin unused reference checking performed in
PostHighlighingPass finds unused refs that really are used in our
language.  Mostly this has to do with how our Psi tree is structured.
In any case, our language performs its own extensive unused ref
checking, therefore we'd like to disable intellij's somehow if
possible.  Please advise.  Thanks!

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

Thanks Dmitry.  Unfortunately (or fortunately, however you look at it) we are leveraging some builtin features we get for free by implementing PsiClass etc. so we are stuck with PsiIdentifier and friends, for the time being anyway.  The ImplicitUsageProvider interface sounds interesting, but it still involves the post highlightign pass which seems totally unnecessary for us given our language performs all the analysis we need -- we want to avoid the overhead of the IJ's analysis if possible.  To that end I was wondering if we could use HighlightingSettingsPerFile to circumvent it.  Does that seem ok to you?  Thanks.

Hello Scott,

Even though your classes implement PsiClass, your references to those classes
usually don't need to implement PsiIdentifier.

You can probably make it work with HighlightingSettingsPerFile, but this
looks like a hack to me.

Thanks Dmitry.  Unfortunately (or fortunately, however you look at it)
we are leveraging some builtin features we get for free by
implementing PsiClass etc. so we are stuck with PsiIdentifier and
friends, for the time being anyway.  The ImplicitUsageProvider
interface sounds interesting, but it still involves the post
highlightign pass which seems totally unnecessary for us given our
language performs all the analysis we need -- we want to avoid the
overhead of the IJ's analysis if possible.  To that end I was
wondering if we could use HighlightingSettingsPerFile to circumvent
it.  Does that seem ok to you?  Thanks.

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"

Thanks, Dmitry.  The PsiClass and related API seems to require PsiIdentifier e.g., PsiIdentifier getNameIdentifier().  The bottom line is we get immediate benefit from implementing PsiClass and appearing to IJ as Java at some level e.g., structure view.  Someday we'll implement those completely, but for now we're choosing to leverage what we can while filling out more fundemental features, if the two ideas aren't in too much conflict.

Yeah, the HighlightingSettingsPerFile approach does seem rather hacky.  The only reason I consider doing that is it avoids the IJ analysis phase altogether, which seems most appropriate for us.  How would you recommend we use HighlightingSettingsPerFile?  I'm a little confused as to where we hook into this.  Thanks.

Btw, I went ahead and implemented a ImplicitUsageProvider extension and all seems ok.  As always thanks for your help!

Hello Scott,

It's actually a fault in the API; there's no reason why PsiClass.getNameIdentifier()
needs to return a PsiIdentifier and not an arbitrary PsiElement.

Thanks, Dmitry.  The PsiClass and related API seems to require
PsiIdentifier e.g., PsiIdentifier getNameIdentifier().  The bottom
line is we get immediate benefit from implementing PsiClass and
appearing to IJ as Java at some level e.g., structure view.  Someday
we'll implement those completely, but for now we're choosing to
leverage what we can while filling out more fundemental features, if
the two ideas aren't in too much conflict.

--
Dmitry Jemerov
Development Lead
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"