You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Header files should be handled like "import" in Python or "use" in Fortran. A header file, together with an optional associated cpp file, will create one ASR module, that will be saved to a .mod file. Then when an include happens, the mod file is loaded. So we will have access to all the source code (whether in .h or in .cpp).
Our parser should thus parse include lines into an HeaderInclude AST node, like an import statement.
This will allow very fast compilation and robust error messages. It will not allow circular dependencies and other corner cases (such as various preprocessor macro tricks), but as a user I do not want those anyway. We will eventually allow a preprocessor, but it would work like the preprocessor in LFortran, on a per file basis.
Parsing will thus be strictly local only, each .h or .cpp file can be fully parsed to AST, no need to look elsewhere. Then in AST->ASR, intrinsic C++ header files (and supported 3rd party libraries) are handled directly (we do not actually include any header file) and user defined header files are handled by compiling those as ASR modules first, and then loading them as ASR modules.
The text was updated successfully, but these errors were encountered:
Header files should be handled like "import" in Python or "use" in Fortran. A header file, together with an optional associated cpp file, will create one ASR module, that will be saved to a
.mod
file. Then when an include happens, the mod file is loaded. So we will have access to all the source code (whether in.h
or in.cpp
).Our parser should thus parse include lines into an
HeaderInclude
AST node, like an import statement.This will allow very fast compilation and robust error messages. It will not allow circular dependencies and other corner cases (such as various preprocessor macro tricks), but as a user I do not want those anyway. We will eventually allow a preprocessor, but it would work like the preprocessor in LFortran, on a per file basis.
Parsing will thus be strictly local only, each
.h
or.cpp
file can be fully parsed to AST, no need to look elsewhere. Then in AST->ASR, intrinsic C++ header files (and supported 3rd party libraries) are handled directly (we do not actually include any header file) and user defined header files are handled by compiling those as ASR modules first, and then loading them as ASR modules.The text was updated successfully, but these errors were encountered: