Indexing process should not rely on non-indexed file data

Answered

Hello,

I'm fighting with: "java.lang.Throwable: Indexing process should not rely on non-indexed file data."

What I thought it might cause is, when after changing a file, which fires up re-index, I'm accessing an index of the very same file. But that seems not to be an issue.

Instead I'm accessing an index of a different FileType entirely, which causes this crash while also right after error it does indexing again and this time it's successful. So after some edit I always get an error, which is right away resolved by itself - but I'd like to avoid it if possible.

I'll try to describe:
I have 2 different FileTypes (.gd, .tscn) -> each with it's own parser, lexer, indices and so on.

.tscn is parsed ok, it creates stub elements which are indexed and visible in IndexViewer plugin.

Then inside .gd is element which uses data from .tscn file so when I'm creating a stub for .gd element I look into .tscn index and that causes an error "should not rely on non-indexed file data"

But .tscn file should be already processed and indexed. I've even tried to add Dumb checks, but it still calls and crashes:

if (DumbService.isDumb(element.project)) return emptyList();

return DumbService.getInstance(element.project).runReadActionInSmartMode<Collection<Psi>> {
get(key, element.project, GlobalSearchScope.allScope(element.project))
} ?: return emptyList();
Indexing file = C:/Users/david/Desktop/Example/Node3D.gd, file id = 27, queried file id = 21
java.lang.Throwable: Indexing process should not rely on non-indexed file data.
Indexing file = C:/Users/david/Desktop/Example/Node3D.gd, file id = 27, queried file id = 21
    at com.intellij.openapi.diagnostic.Logger.error(Logger.java:184)
    at com.intellij.indexing.composite.CompositeInvertedIndexBase.doGetIndexedFileData(CompositeInvertedIndexBase.java:160)
    at com.intellij.indexing.composite.CompositeInvertedIndexBase.getIndexedFileData(CompositeInvertedIndexBase.java:142)
    at com.intellij.psi.stubs.StubProcessingHelper.retrieveStubIdList(StubProcessingHelper.java:38)
    at com.intellij.psi.stubs.StubIndexEx.lambda$processElements$6(StubIndexEx.java:178)
    at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1708)
    at com.intellij.psi.stubs.StubIndexEx.processElements(StubIndexEx.java:177)
    at com.intellij.psi.stubs.StubIndex.processElements(StubIndex.java:50)
    at com.intellij.psi.stubs.StubIndex.get(StubIndex.java:40)
    at com.intellij.psi.stubs.AbstractStubIndex.get(AbstractStubIndex.java:22)
    at common.index.StringStubIndexExtensionExt.getGlobally$lambda-0(StringStubIndexExtensionExt.kt:23)
    at com.intellij.openapi.project.DumbService.lambda$runReadActionInSmartMode$0(DumbService.java:113)
    at com.intellij.openapi.project.DumbService.runReadActionInSmartMode(DumbService.java:144)
  at com.intellij.openapi.project.DumbService.runReadActionInSmartMode(DumbService.java:113)

I don't even see CompositeInvertedIndexBase file in library to debug it - or rather I don't see whole com.intellij.indexing package.

1) First question is - is it completly a wrong idea to rely on indicies while building a StubTree? It's mostly to store dataTypes inside a stub, f.e.: when I declare a variable I want to know it's return type inside a stub, because as in this example it comes from different FileType -> or do I have to avoid using indices while building a stub entirely and only resolve it when later asking for that dataType?

2) If it's ok to use indices (which seems ok for all other cases when it's within files of the same fileType) could you hint direct me for possible solution?

Thank you yet again for any response.

Have a nice day.

0
2 comments

Hi,

If I understand correctly, you try calculating some data while building the stub tree to know it in advance for other features like resolving, completions, etc.

You shouldn't do it. Information like this should be calculated as late as possible, only when needed, e.g., when resolving is performed. It can be cached so that it will be computed only once. In fact, calculating it without being sure it will be used is performance degradation.

1

Ah, ok never thought about it the other way around - calculated not needed values.
Thank you.

0

Please sign in to leave a comment.