Open jyn514 opened 4 years ago
If #356 is implemented, the preprocessor could instead run between the lexer and the parser. This would clean up the current somewhat hacky way the preprocessor consumes the lexer's characters for it. It would also allow people to opt-in/out of the preprocessor.
Suggested by @pythondude325. Related to #151.
It would be really cool to have a separate library which serializes and deserializes C source code. Most of the serialization is already done in
src/data
in variousimpl Display
s. The hard part will be factoring apart the lexer/parser from the rest of the compiler. The syntax part of this is already hard as noted in #151, but separating the preprocessor would also be somewhat difficult: I'd have to duplicate a fair bit of code (lexing tokens mostly) and have a way to pass locations around.Related facts:
#include
as long as they are valid UTF8 (including things that would normally be lexer errors)#if
as long as they only contain integer constantsMy proposed plan is this:
logos
andLALRPOP
. This will do absolutely no semantic checking, only parsing. This will be the library.#if
, add anexpr()
API to the serde parser. To allow keeping track of multiple files add a metadata field to location:This allows people who don't care to leave it blank (
()
) and people who do care to pass aFileId
or similar.Open questions:
#include
s? (devsnek on #lang-dev recommended calling a user-defined function - that would need to be aware of local vs. global includes as well as search paths).rcc
crate with codegen behind a feature flag?