| 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.
|
|
Escaped newlines
|
|
This also serves as a regression test for the recent preprocessor bug fix.
|
|
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.
|
|
Rename tests from `*.spire` to `*.slang`
|
|
Many of the existing test cases were being skipped on accident, because their file names used `.spire` and the test tool was now looking for `.slang`
|
|
GLSL: get GLSL limping in `render-test`
|
|
The test case that is there right now is nominally a cross-compilation test, but for right now it uses the preprocessor to present completely different code for HLSL and GLSL compilation.
This change is really just fleshing out the OpenGL side of `render-test` enough that it can produce images using OpenGL to enable further testing.
|
|
AppVeyor: try to produce a better build version
|
|
|
|
- Also add link to build "badge" so that I can more easily watch build status.
|
|
I don't want to have to try and manually keep a version number in `appveyor.yml` up to date with any versioning for releases, etc.
This change tries to derive a reasonable version name from a Git tag, a pull request number, or a branch name (in that order).
I then append the AppVeyor build number to the end to try to ensure that we always have something unique (which is a requirement for AppVeyor).
|
|
- Add an `install` step that tries to update our submodules (just `glslang` at the moment)
- Try to add a "badge" image to the main `README.md`
|
|
|
|
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`.
|
|
Some files seem to have been removed since I last sync'ed the glslang code.
|
|
This is currently required for GLSL->SPIR-V compilation and related tests.
|
|
|
|
|
