Missing C++20 modules imports in -ast-dump

[vagran]

test.cpp:

import std.core;

int i;

Running command clang++ -std=c++20 -Xclang -ast-dump -fsyntax-only test.cpp gives this result:

test.cpp:1:8: fatal error: module 'std.core' not found
import std.core;
~~~~~~~^~~
TranslationUnitDecl 0x5590c7227c58 <<invalid sloc>> <invalid sloc>
|-TypedefDecl 0x5590c72284e0 <<invalid sloc>> <invalid sloc> implicit __int128_t '__int128'
| `-BuiltinType 0x5590c7228220 '__int128'
|-TypedefDecl 0x5590c7228558 <<invalid sloc>> <invalid sloc> implicit __uint128_t 'unsigned __int128'
| `-BuiltinType 0x5590c7228240 'unsigned __int128'
|-TypedefDecl 0x5590c7228910 <<invalid sloc>> <invalid sloc> implicit __NSConstantString '__NSConstantString_tag'
| `-RecordType 0x5590c7228660 '__NSConstantString_tag'
|   `-CXXRecord 0x5590c72285b8 '__NSConstantString_tag'
|-TypedefDecl 0x5590c72289b8 <<invalid sloc>> <invalid sloc> implicit __builtin_ms_va_list 'char *'
| `-PointerType 0x5590c7228970 'char *'
|   `-BuiltinType 0x5590c7227d00 'char'
|-TypedefDecl 0x5590c7273260 <<invalid sloc>> <invalid sloc> implicit __builtin_va_list '__va_list_tag[1]'
| `-ConstantArrayType 0x5590c7273200 '__va_list_tag[1]' 1 
|   `-RecordType 0x5590c7228ac0 '__va_list_tag'
|     `-CXXRecord 0x5590c7228a18 '__va_list_tag'
`-VarDecl 0x5590c72732d8 <test.cpp:3:1, col:5> col:5 i 'int'
1 error generated.

There is no entry for import statement.

BTW Shouldn't -fsyntax-only prevent from module lookup errors?

$ clang++ --version
clang version 16.0.0 (https://github.com/llvm/llvm-project.git ee761374f797a47919ec8f9f49f9b8b1b20573e8)
Target: x86_64-unknown-linux-gnu
Thread model: posix

[llvmbot]

@llvm/issue-subscribers-clang-modules

[iains]

test.cpp:

import std.core;

int i;

Running command clang++ -std=c++20 -Xclang -ast-dump -fsyntax-only test.cpp gives this result:

test.cpp:1:8: fatal error: module 'std.core' not found
import std.core;
~~~~~~~^~~
TranslationUnitDecl 0x5590c7227c58 <<invalid sloc>> <invalid sloc>
|-TypedefDecl 0x5590c72284e0 <<invalid sloc>> <invalid sloc> implicit __int128_t '__int128'
| `-BuiltinType 0x5590c7228220 '__int128'
|-TypedefDecl 0x5590c7228558 <<invalid sloc>> <invalid sloc> implicit __uint128_t 'unsigned __int128'
| `-BuiltinType 0x5590c7228240 'unsigned __int128'
|-TypedefDecl 0x5590c7228910 <<invalid sloc>> <invalid sloc> implicit __NSConstantString '__NSConstantString_tag'
| `-RecordType 0x5590c7228660 '__NSConstantString_tag'
|   `-CXXRecord 0x5590c72285b8 '__NSConstantString_tag'
|-TypedefDecl 0x5590c72289b8 <<invalid sloc>> <invalid sloc> implicit __builtin_ms_va_list 'char *'
| `-PointerType 0x5590c7228970 'char *'
|   `-BuiltinType 0x5590c7227d00 'char'
|-TypedefDecl 0x5590c7273260 <<invalid sloc>> <invalid sloc> implicit __builtin_va_list '__va_list_tag[1]'
| `-ConstantArrayType 0x5590c7273200 '__va_list_tag[1]' 1 
|   `-RecordType 0x5590c7228ac0 '__va_list_tag'
|     `-CXXRecord 0x5590c7228a18 '__va_list_tag'
`-VarDecl 0x5590c72732d8 <test.cpp:3:1, col:5> col:5 i 'int'
1 error generated.

There is no entry for import statement.

As things stand, an import is not generated in the case that the import fails completely - we create a dummy module for the purpose of error-recovery that is all. I am not sure what useful information could be presented (the error could be arbitrary)

BTW Shouldn't -fsyntax-only prevent from module lookup errors?

An interesting question; At the moment the imported module is required - since subsequent Sema actions can depend on it or its content.

[vagran]

I have checked with proper arguments for module lookup, then it works as you said.

Quite sad, I planned to use Clang for C++ files parsing to figure out module dependencies for my C++ modules build system. I had an impression that Clang is designed to provide "compiler as service" functionality for such kind of things.

[iains]

Quite sad, I planned to use Clang for C++ files parsing to figure out module dependencies for my C++ modules build system. I had an impression that Clang is designed to provide "compiler as service" functionality for such kind of things.

Hopefully we can reduce the sadness ... the compiler infrastructure is designed to do what you want - but in a slightly different manner.

There are mechanisms being worked on for implementing the modules dependencies discovery - as part of the tooling support (e.g. in the manner of scan-build, scan-deps) and there is active discussion on the topic in SG15 (tooling sub-group for WG21).