mirror of
https://github.com/eclipse-cdt/cdt
synced 2025-04-23 06:32:10 +02:00
cb0797481f
__has_include_next (extension) __has_include evaluates whether of the header name passed as parameter exists. This can only be evaluated as part of a #if directive. Interestingly, it also has to be reported as defined, i.e. #if defined(__has_include) or #ifdef. In order to report this as defined, this implementation adds it as a macro but during macro expansion, it's actually converted as a dedicated token type. Then this token gets evaluated during normal preprocessor expression evaluation. In order to parse header names, there were several options. The main problem is that header tokens (tQUOTE_HEADER_NAME, tSYSTEM_HEADER_NAME) are actually produced by the Lexer as part of a special mode (setInsideIncludeDirective) set during the handling of #include. For expression evaluation, the tokens are already generated without setInsideIncludeDirective therefore we only have plain string and < > tokens. One approach would be to generate header tokens "earlier" than executing we need to track a new state while fetching token to configure the Lexer (setInsideIncludeDirective) when in the context of an __has_include. There are also complications due to macro expansion within the __has_include where after one expansion, we don't have a lexer in the context anymore, introducing more changes. Another approach would be to remove the Header token creation from the Lexer itself and let the preprocessor assemble the tokens into an header string, in both cases of #include and __has_include. This mostly works and is the approach used in Clang, but the problem is that whereas Clang keeps track of leading spaces of tokens, CDT doesn't. This means with such change that CDT would now allow #include < iostream > (notice the white space). I think this is too big of a downside and also too big of a change to introduce this handling of whitespace at the token level. The approach used here is more conservative and isolated but also shares less common logic with #include processing. The non-header token (string, <, etc) are assembled into a header string only in the case of a __has_include. So a downside will be that #include and __has_include will be inconsistent in regards of leading/trailing space parsing but I feel like this is better than making #include more permissive. Change-Id: I5b9f5c616c8d999e0c916a85b41f96e20037b651 Signed-off-by: Marc-Andre Laperle <malaperle@gmail.com> |
||
|---|---|---|
| .. | ||
| org.eclipse.cdt.core | ||
| org.eclipse.cdt.core.linux | ||
| org.eclipse.cdt.core.linux.aarch64 | ||
| org.eclipse.cdt.core.linux.ppc64le | ||
| org.eclipse.cdt.core.linux.x86_64 | ||
| org.eclipse.cdt.core.macosx | ||
| org.eclipse.cdt.core.native | ||
| org.eclipse.cdt.core.tests | ||
| org.eclipse.cdt.core.win32 | ||
| org.eclipse.cdt.core.win32.x86_64 | ||
| org.eclipse.cdt.ui | ||
| org.eclipse.cdt.ui.tests | ||
| pom.xml | ||