| Age | Commit message (Collapse) | Author |
|---|
|
This is really messy and I'm not entirely happy with the result, but at least we handle a couple more corner cases.
|
|
This is mostly to allow for the idiomatic style of defining a multi-line macro in C:
#define FOO(a,b) \
x(a) \
y(b) \
/* end */
The handling is reasonably general: in the lexer whenever we need to consume or "peek" the next code point, we check if we are at the start of a backslash-newline sequence, and if so we skip past that to find what we were looking for.
However, the way I'm handling things right now there is no step taken to "clean" a token and remove the backslash or newline from its value, so downstream code that actually inspects token values will probably break if users start putting escaped newlines in the middle of names.
We can fix that issue when (if) it comes up.
|
|
There was a subtle bug when a function-like macro with multiple arguments expands to use the arguments one after the other:
#define FOO(a,b) a b
FOO(int, x);
During expansion, the input streams look something like (using `.` to represent the cursor):
// macro invocation:
FOO(int, x) . ;
// macro expansion of `FOO(int, x)`
a . b
// macro argument `a`
int .
That is, we are at the end of the first argument's tokens.
When "peeking" the next token, we correctly work up the list of active streams until we find one that isn't at its end, and that gives us the token `b`.
But then we need to look up `b` in an appropriate environment to find what it is bound to.
Each of the streams above has an environment asociated with it, and in particular, `b` is only defined in the middle environment, because that is where the macro arguments were registered.
The simple fix here is to make the lookup logic for finding an environment follow the same logic as finding the next token.
A more complete fix down the line could involve getting rid of the approach of allowing an input stream to be "active" but at its end.
I believe this was originally required to handle some error cases in directives, where we'd want to keep the input stream for one file active until we are done parsing a full directive from it (e.g., if a directive is on the last line of the file).
Now that we generate an explicit "end of directive" token, that may not be required.
|
|
All of this is just related to cruft left over from the old project setup.
|
|
There were some dead project references lying around after the Spire->Slang rename, that don't affect builds from inside Visual Studio, but seem to break stand-alone build with `msbuild`.
|
|
|
