support for #include "file.ext" directive Follow
Answered
I need to implement support for #include “file.ext” directive in my custom language.
Idea behind this directive is the same as in other languages like C or C++.
I need to have access to included file at lexer and parser level but that path of included file is relative to current document. Lexer interface takes as an input CharSequence and it does not understand files, so I cannot resolve relative file name to absolute path.
Do you know any solution to this problem?
Please sign in to leave a comment.
Unfortunately there is currently no sample code for your setup I'm aware of that we can share. You might try and browse for existing language plugins and find a similar use case https://plugins.jetbrains.com/search?products=idea&tags=Languages
For managing file include information at later stages, com.intellij.psi.impl.include.FileIncludeProvider could be used.
Good news, today I can share some instructions. HTH.
Hi Yann,
Many thanks for your very detailed explanation! It helped me to confirm that my approach is correct as it is almost the same now. I hope I will not get stuck somewhere dramatically.
Thanks also for linking this answer to my previous question. Both questions are related to preprocessing but this is more specific and assumes that the general solution is already worked out, so let me follow up on it here. I will ask some additional questions in the previous thread.
--------------------
My general problem raised in this thread is still not clear to me.
Let me quote relevant fragments from your answer:
After returning all the <#include> and <string> back, the lexer queries all symbols from header.h and especially all #DEFINES.
...
ParserDefinition.createLexer(Project) is sometimes called with "null" But "real" files are lexed/parsed via IFileElementType or IStubFileElementType API
What does it mean “lexed via IFileElementType”? Lexer interface accepts CharSequence only and there is no information about the containing file. Also Lexer instance is created using ParserDefinition.createLexer(Project) which gives us the context of the project, not the file.
In the presented example header.h is (or could be) relative to source.c. How Lexer can find header.h file if it does not about source.c?
This is great stuff Yann, thanks for such a detailed answer. I've filed it away in case I ever need to do this.
I have one question - as far as I am aware, it's a basic restriction that index information for a file should only be based on that file's contents, not on any other file's content. This is so that the index invalidation works correctly when files are modified. This implementation is a clear violation of that, how should that be handled? Can the index information for source.c be invalidated somehow when header.h is modified? Or is some other approach recommended?