slang.git - Making it easier to work with shaders

Age	Commit message (Collapse)	Author
2017-07-22	Make the "hack" sampler explicit for now	Tim Foley
	- We use this to work around the fact that, e.g., `Texture2D.Load` doesn't take a sampler, but the equivalent GLSL operation `texelFetch` requires one - Previously we tried to hide the sampler from the user, hoping that glslang would drop it and we could just ignore it, but that doesn't work - For now we'll go ahead and explicitly show the sampler in the reflection info so that an app can react appropriately - We also generate a unique binding for the sampler, instead of the old behavior that fixed it with `binding = 0` - We still fix it with `set = 0`, so it might still surprise users
2017-07-21	Add an API option to control emission of `#line` directives	Tim Foley
	- API users can use this to get "clean" output to aid with debugging Slang issues - Also changes the prefix on intermediate files that Slang dumps, to make them easier to ignore with a regexp
2017-07-20	Translate NV single-pass stereo extension from Slang to GLSL	Tim Foley
	- The easy part here is treating `NV_` prefixed semantics as another case of "system-value" semantics - Mapping the new semantics (`NV_X_RIGHT` and `NV_VIEWPORT_MASK`) to their GLSL equivalents is harder - Instead of a single "right-eye vertex" output, GLSL defines an array of per-view positions - Instead of a vector of masks, GLSL defines an array of per-view masks - Another point here is that a lot of semantics that appear as `uint` in HLSL are `int` in GLSL, which can lead to conversion issues. - The approach here is to have the lowering pass introduce a notion of assignment with "fixups," which will try to cast things as needed - When assigning to a simple value with the "wrong" type, introduce a cast - When assigning to an array from a vector, break out multiple assignments of individual vector/array elements - In order to facilitate the above, I needed to add actual types to the magic expressions I introduce to represent GLSL builtin variables. These were taken by scanning the online documentation for GL, so they might not be perfect. - Major issues with the approach in this change: - No attempt is being made here to check that the original declaration used a type appropriate to the semantic. The assumption is that this logic only ever triggers for Slang entry points, or GLSL entry points using a Slang `struct` type for input/output (and for right now Slang code is only ever written by "understanding" developers) - In the case of a Slang entry point, we always copy varying parameters in/out around the call to `main_`, so this approach should handle calls to functions with `out` or `in out` parameters okay, but it is not robust to cases where we don't want to copy in all the entry point parameters first thing (e.g., a GS), so that will have to change - In the GLSL case (or if we revise the approach to Slang entry points), there is going to be a problem if these converted varying parameters are ever passed as arguments to `out` or `in out` parameters. In these cases we need to do more sleight-of-hand to reify a temporary variable and do the necessary copy-in/copy-out. Being able to do that logic relies on having correct information about callees, which requires having robust semantic analysis of the function body. There is only so much we can do... - A better long-term approach would not rely on an ad-hoc "fixup" conversion during assignment, but would instead implement the GLSL builtin variables as, effectively, global "property" declarations that have both `get` and `set` accessors, and then tunnel a reference to such a property down through lowering, where it can lower to uses of the "getter" or "setter" as appropriate in context (and the result type of the getter/setter can be what we'd want/expect).
2017-07-19	Try to improve handling of failures during compilation	Tim Foley
	The change is mostly about trying to make sure the compiler "fails safe" when it encounters an internal assumption that isn't met. Most internal errors will now throw exceptions (yes, exceptions are evil, but this will work for now), and these get caught in `spCompile` so that they don't propagate to the user (they just see a message that compilation aborted due to an internal error). Subsequent changes are going to need to work on diagnosing as many of these situations as possible, so that users can at least know what construct in their code was unexpected or unhandled by the compiler.
2017-07-19	Fix up translation of `GetDimensions()`	Tim Foley
	Fixes #122 - In cases with an explicit mip level being specified, there was a mistake in how the argument for setting the mip level in the GLSL code was constructed that led to a parse error in GLSL - Also, that argument is a `uint` in HLSL and an `int` in GLSL, so an explicit cast was needed - The GLSL functions here seem to require a newer GLSL (at least higher than `420`), so I had to add in a capability for builtins to specify a required GLSL version. For now I made these ones require `450`. - Added a test case to confirm that our lowering works (for some definition of "works")
2017-07-18	Swizzle result of buffer load based on element type	Tim Foley
	When lowering `buf[i]` to `texelFetch(..., i)` we need to deal with the case where the type of `b` might be `Buffer<float>` in which case we want to add a `.x` swizzle to the end of the fetch.
2017-07-18	Support scalarization of varying input/output for GLSL	Tim Foley
	GLSL technically supports varying (`in`, `out`) parameters of `struct` type, but there are some annoying constraints (not allowed for VS input), and it doesn't work with how an HLSL user would usually put "system-value" inputs/outputs into a `struct` together with ordinary inputs/outputs. To work around this, this change adds support for using an imported Slang `struct` type for an `in` or `out` parameter, in which case it will (1) be scalarized and (2) will have system-value semantics mapped appropriately, just as for an entry-point parameter when cross-compiling an HLSL-style `main()`. Changes: - Add a notion of a `VaryingTupleExpr` and `VaryingTupleVarDecl`, similar to those for the resources-in-structs case - Trigger use of these when we have a global-scope varying in/out using an imported `struct` type - Also use these in the cross-compilation case for ordinary varying input/output (since this approach seems like it should be more general, and can hopefully handle stuff like GS input/output some day) - When generating parameter binding information, special case global-scope input/output, and treat it the same as entry-point-parameter input/output - Revamp how used resource ranges are computed so that we can eventually make this specific to an entry point - Actually implement first signs of life for `maybeMoveTemp` so that assignments to the tuple-ified outputs will work better - Add first test case that actually seems to work - Add diagnostics for conflicting explicit bindings on a parameter - Add diagnostic for different parameters with overlapping bindings - Make global-scope varying input/output use a tracking data structure specific to the translation unit for computing locations (so that they are independent of other TUs)
2017-07-17	Handle `Buffer` types more like textures	Tim Foley
	Fixes #94 We'd been handling HLSL `Buffer` and `RWBuffer` in a one-off fashion, and that led to a lot of code duplication, and also to the issue that we weren't handling `RasterizerOrderedBuffer` at all. This change basically folds `Buffer` in so that it is conceptually a texture type (just with a unique shape). Hopefully all the other logic still works.
2017-07-17	Improve handling of `SampleCmpLevelZero`	Tim Foley
	- We map `SampleCmpLevelZero` to either `textureLod` or `textureGrad` based on what the GLSL spec seems to allow - We map `SamplerComparisonState` to `samplerShadow` (instead of just `sampler`)
2017-07-17	Map HLSL `linear` to GLSL... nothing	Tim Foley
	The behavior of the `linear` modifier should be the default interpolation behavior in GLSL.
2017-07-17	Pick correct GLSL version when `gl_Layer` used	Tim Foley
	`gl_Layer` as a fragment input requires at least version 4.30 of GLSL, so we try to track that information when we see the name used. Note that this does not override a user-specified `#version` line. This required re-ordering when lowering happens relative to emitting the `#version` directive, since this code works by actually modifying the chosen profile for the entry point. Yes, that is kind of gross and we should do something cleaner in the long term.
2017-07-17	Add emit logic for generic app expressions	Tim Foley
	Work on #105 These can occur in unchecked code (or code that had a semantic error), so we need to be able to handle them.
2017-07-17	Handle `flat` interpolation cases in cross compilation	Tim Foley
	Fixes #104 - Map HLSL `nointerpolation` to GLSL `flat` - When lowering a `struct` type varying input/output, look for interpolation modifiers along the "chain" from the leaf field up to the original shader input variable (and take the first one found) - Not sure if this is strictly needed, but it seems like a reasonable policy - Add `flat` to varying input of integer type, with no other interpolation modifier - Note: I do not do anything to ignore a manually imposed interpolation modifier that might be incorrect
2017-07-14	Don't assign a `binding` to a `push_constant` buffer	Tim Foley
	Fixes #12 - This was a latent issue, but the previous commit brought it to the front. - As indicated in #12, I don't allocate a descriptor-table slot to the block - Instead I allocate a `PushConstantBuffer` - Unlike what #12 asks for, I don't use a different resource type for the contents of the block - Pretty much all the logic is easiest if these continue to be just plain `Uniform` data
2017-07-13	Allow GLSL `#version` to be selected based on profile	Tim Foley
	Fixes #83 - The basic idea is that I added a bunch of more specific profile names line `glsl_vertex_430` which indicate the desired GLSL version the user wants. - An explicit `#version` line in the code always overrides one specified by profile, though
2017-07-13	Don't emit C-style `#line` directives when directly generating GLSL	Tim Foley
	- This fixes the render tests, which aren't tested by the continuous integration setup - This was broken in the commit that decided to use C-style directives all the time. - This works for stuff that eventually passes through glslang (or at least our build of it) - It doensn't work if we take the GLSL and pass it off to an OpenGL driver (which is what I do for testing) - A longer-term fix is still required to deal with line directives properly
2017-07-12	Add ability for intrinsics to require GLSL extensions	Tim Foley
	When cross-compiling, we need to detect when an intrinsic is used that required non-default GLSL capabilities and emit an appropriate `#extension ... : require` line. I'm handling this by attaching a custom modifier to declarations that require an extension in order to be callable.
2017-07-12	Don't emit interpolation modifiers on struct fields when outputting GLSL	Tim Foley
	HLSL (and thus Slang) commonly puts interpolation modifiers like `sample` on the fields of `struct` types used as stage input/output, while GLSL only allows them on global-scope `in` and `out` variables (or ones in blocks). This change emits a really hacky filtering step to skip over certain modifiers when emitting a declaration. This lets us skip interpolation-mode modifiers when outputting a struct field to GLSL. Note: this probably gets the `in` or `out` block case wrong...
2017-07-12	Use C-style line directives, even for GLSL	Tim Foley
	- As long as we are always going to pass GLSL through glslang, there should be no harm in this - Eventually we may need to re-enable the old style
2017-07-12	Add basic reflection query for checking if entry point is "sample-rate"	Tim Foley
	- This really just checks two basic things: 1. Was there any global variable declared with `in` and `sample`? 2. Did any code encountered during lowering referenece `gl_SampleIndex`? - This doesn't cover what HLSL could need, nor what we would need for cross-compilation. Consider it GLSL-specific for now. - In order to generate the information with even a reasonable chance of being accurate (not giving a ton of false positives) I tried to integrate the checks into the lowering process (so they only see code that is referenced, one hopes). - For this to work with my testing setup, I needed to make sure that lowering is always performed, prior to emitting reflection info - This change broke several reflection tests, because they had been using code that wouldn't actually pass the downstream compiler. I checked in fixes for those.
2017-07-11	Bug fixes for resources-in-structs.	Tim Foley

2017-07-11	Initial work on handling resources in structs during cross-compilation	Tim Foley
	- The basic idea is that during the "lowering" pass, some types (notably: aggregate types that contain resource variables) will get turned into "tuple" types, which are pseduo-types that aren't meant to survive lowering. - An attempt to declare a variable with a tuple type expands into a tuple of declarations - An attempt to reference such a tuple-ified variable leads to a tuple of expressions - An attempt to extract a member from such a tuple expression will pick the appropriate sub-element - Dereference a tuple by dereferencing the primary expression - Expand a tuple in the argument list to a call into N arguments (by recursively flattening the tuple) - Don't create tuple types when not generating GLSL - Make sure to preserve the specialized type of a call expression through lowering, since emission of unchecked calls relies on that info. - TODO: maybe the infix/prefix/postifx/select information should come in as a side-band? Should we have modifiers on expressions? - Make sure to offset the layout for a nested field based on teh base offset of its parent variable, when generating declarations for nested fields
2017-07-10	Handle function name properly for unchecked call	Tim Foley
	The emit logic was checking for a missing decl, and then asking that same (missing) declaration for its name.
2017-07-10	Fix emission of `static` for HLSL	Tim Foley
	I forgot to include a trailing space.
2017-07-10	Add support for `imageBuffer`	Tim Foley
	This was mostly just a missing `typedef` in the Slang standard library code. This should also cover `textureBuffer` and `samplerBuffer`.
2017-07-10	Try to be more robust against un-checked types during lowering, etc.	Tim Foley
	- Try to handle `ErrorType` gracefully when computing type layouts - When outputting a `TypeExp`, if the type part is errorneous (or missing), try to use the expression part - Make sure to lower the expressions side of a `TypeExp` during lowering
2017-07-10	Cleanups for test cases:	Tim Foley
	- Allow a code-generation target of `NONE` in order to suppress ordinary output in test cases where we don't care about the actual output (just pass/fail result) - Add explicit `location` layout qualifiers to intermediate vertex-to-fragment variables in GLSL test cases for rendering, to work around apparent Intel driver bugs.
2017-07-10	More cross-compilation fixes	Tim Foley
	- Add GLSL mappings for more `Texture` methods - The annoying one here is `Texture.Load()` because it doesn't take a sampler, but the GLSL equivalent needs one (while the SPIR-V does not). I've hacked this pretty seriously for now. - Try to ensure that we add `uniform` to global declarations that need it in GLSL - When outputting an `in` or `out` variable that might have been created from an `inout` shader parameter, filter the layout qualifiers that we output to only cover the appropriate resource kind.
2017-07-08	Move renaming logic to lowering pass.	Tim Foley
	Code in Slang that is cross-compiled might introduce declarations that collide with language keywords that are reserved in the target. This was previously being dealth with during final code emission, but the challenge there is that we want to allow user code that is being "rewritten" to use whatever identifiers it wants (they know better than us what is an error), and only apply renaming to our own code. The approach here is to apply renaming during lowering - we validate each declaration to make sure its name is valid. Any expressions/types that refer to those declarations will automatically get emitted with the new name (while unchecked expressions will continue to be emitted with their existing name). This isn't quite perfect, since we could in theory still rename a declaration in user code. A more robust version down the line would try to determine if a declaration was nested inside code for the "rewriter." Also note that this does not deal with any issues of name conflicts that might arise between modules. That would require a more complete and robust renaming pass, which seems tricky for me to pull off.
2017-07-08	Add back `UnparsedStmt`	Tim Foley
	If the user doesn't use any `import` declarations, there is no reason to parse their code at all, so having the option of falling back to `UnparsedStmt` can potentially save us some headaches down the road. The new rule now is that if you have the "no checking" flag on, and the parser hasn't yet seen any `import` declarations, then it still used `UnparsedStmt` to avoid touching function bodies. Otherwise, I go ahead and parse function bodies, and assume I can rewrite any code I can semantically understand.
2017-07-08	Differentiate HLSL `for` loops in AST	Tim Foley
	HLSL has the bad scoping behavior for `for` loops, and we need to respect that. But, we need to have correct scoping for GLSL, and we'd like it for Slang. We also need to ensure that `for` loops written in a "correct" language get the correct behavior when emitted as HLSL. There was already code to handle this in the emit pass, but it was unfortunately using an `isRewrite` flag to try to tell if the HLSL behavior was wanted. This doesn't work when the code being emitted might come from a mix of languages. This change adds a distinct `UnscopedForStmt` syntax node type, and uses that when parsing HLSL input (bot not for other languages). We make sure to preserve this node type through lowering, and then specialize our emit logic on this case. With this, there are no more remaining uses of `isRewrite` in the emit logic, which is good because it didn't mean what I needed it to mean any more (since we now emit only a single module, that was merged during lowering).
2017-07-08	Revise how hidden implicit casts are recognized.	Tim Foley
	The old approach used an `isRewriter` flag in the emit logic, but I kind of need that flag to go away. Instead, I now how the semantic checking pass detect whether an implicitly-generated type cast is in rewriter code, and if so it uses the new `HiddenImplicitCastExpr` AST node. The emit logic then looks for that specific node and eliminates it.
2017-07-08	Try to emit expressions with minimal parentheses	Tim Foley
	When emitting code it is easy to be overly defensive and emit tons of extra parentheses. In some cases these are just annoying, and make the output more cluttered than it needs to be. In other cases, though, being over-aggressive here can actually break things when a downstream compiler has more stringent requirements (e.g., doesn't allow a general expression for the function in a call expression, but only a particular set of atomic/postfix expressions). This wasn't as bad when we weren't parsing function bodies in user code, but now that we are it becomes important to not emit bad parentheses and screw up their code. At the same time, though, we don't want to fail to output them and silently break code. A nice property today is that we preserve parentheses in the input code, so hopefully we don't ever break operator precedence. The code already had an approach to avoid some parens, by tracking an "outer precedence" and only emitting parens for an expression if they were needed relative to this outer precedence. That approach doesn't handle associativity, and so it doesn't work for things like chains of postfix operators. The new approach basically tracks two outer precedence levels: one on the left, and one on the right. When recursing into a sub-expression of an op (e.g., the `A` in `A + B`) on of the precdence levels for the recursive call will come from the outer environment, and the other from the operation itself (e.g., `A` has `(X, +)` as its left/right precdence, where `X` is whatever was to the left of `A + B`, while `B` gets `(+,Y)`). One more piece of the puzzle is that an operator like `+` actually exposes two precedence levels: one for the left-hand side and one for the right-hand, so that if both `A` and `B` are themselves uses of `+`, `A` won't get parens, but `B` will. Finally, when we have an un-checked application of an operator (which our AST stores as something like a function-call node), we do a little lookup step to find the corresponding operator and its precedence (while for things that actually got resolved we know the precedence.
2017-07-08	Fully parse function bodies, even in "rewriter" mode	Tim Foley
	This is in anticipation of needing to have more complete knowledge to be able to handle user code that `import`s library functionality. The big picture of this change is just to remove the `UnparsedStmt` class that was used to hold the bodies of user functions as opaque token streams, and thus to let the full parser and compiler loose on that code. That is the easy part, of course, and the hard part is all the fixes that this requires in the rest of the compielr to make this even remotely work. Subsequent commit address a lot of other issues, so this particular commit mostly represents work-in-progress. One detail is that this change puts a conditional around nearly every diagnostic message in `check.cpp` to suppress thing when in rewriter mode. I have yet to check how that works out if there are errors in anything we actually need to understand for the purposes of generating reflection data.
2017-07-07	Map HLSL `lerp` to GLSL `mix`	Tim Foley
	- Also fix a bug in `emit.cpp` where I wasn't detecting `__intrinsic` remaps that don't include `$` (this is a byproduct of changing the string index type to be unsigned; other bugs like this may be lurking)
2017-07-07	Don't emit `[unroll]` or `[loop]` to GLSL	Tim Foley
	- I really ought to make these semantically understood attributes, which might make this logic easier - Long-term if we start emitting SPIR-V directly, we should translte these, of course
2017-07-07	Add GLSL equivalents for some stdlib operations.	Tim Foley
	- Map HLSL `atan2(y,x)` to GLSL `atan(y,x)` - Add support for `$p` escape in `__intrinsic` modifier, which allows generating GLSL texture-sampler pairs more easily - Also added a `$o` escape to represent the base object in an OOP-style call (`obj.F(...)`) - This isn't used in the texture functions right now, because getting the right GLSL texture type in this context is a bit thorny (the prefix depends on the generic parameter being used) - Used the `$p` capability to add mappings for `SampleBias` and `SampleLevel`
2017-07-07	Overhaul emit logic to use visitor abstraction	Tim Foley
	- This is in preparation for splitting out HLSL vs. GLSL emit as different cases. - Along the way, I added more cases to the visitor implementation, to handle visitors with arguments - This is getting a bit busy, though, and we might be reaching the breaking point where a more general bit of meta-magic is needed to clean things up (either going further down the ugly template route, or plugging in a more real code generation strategy)
2017-07-07	Don't emit the `static` keyword when generating GLSL	Tim Foley
	GLSL doesn't support `static` at all, while HLSL uses it for multiple things: - To mark global variables that are "thread local" rather than shader parameters - In the C/C++ style to mark `static` allocation for variables inside a function or type The latter case needs to be handled during lowering (but isn't handled right now). The former case can be solved just by dropping the `static` keyword.
2017-07-07	Fix signed/unsigned comparison warning.	Tim Foley

2017-07-06	More exhaustive lowering	Tim Foley
	- Handle all statement cases explicitly (rather than falling back to the "structural recursion" mess) - Handle back-references from child statements to their parents
2017-07-06	Fix many warnings-as-errors issues.	Tim Foley
	The code should now compile cleanly with warnings as errors for VS2015 with `W3`. Most of the changes had to do with propagating a real pointer-sized integer type through code that had been using `int`.
2017-07-06	Start to support cross-compilation via "lowering" pass	Tim Foley
	- The big change here is the introduction of a "lowering" pass that takes an input AST from the semantic checker, and produces an output AST suitable for emitting. The intention is that he lowering pass is responsible for: - Stripping out unused code (when we have enough information to do so), by only outputting declarations that are transitively references from an entry point - When cross-compiling to GLSL, generating a suitable `void main()` entry point to wrap the user-written entry-point function - (Eventually) legalizing types in the program, by scalarizing aggregate types that mix uniform and resource types - (Eventually) instantiating generic declarations so that the resulting code only deals with fully specialized declarations - (Eventually) de-sugaring OOP constructs into basic "structs and functions" form - (Eventually) instantiating code that depends on interface types at the concrete types chosen - It is clear that there is still a lot of work to be done there, to this change is really about getting infrastructure in place without breaking the existing test cases. - One cleanup here is that we get rid of the idea of whole-translation-unit output, since that was specific to HLSL output, and there is really no strong reason for keeping it. Users should now just ask for the output for each entry point that they wanted to generate. - The biggest source of complexity for the lowering process is that it needs to produce the same AST structure as the input, to deal with the complexity of the rewriter case. That is, we need the output to be able to reproduce the input exactly in the case where we are rewriting and nothing needs to change, so the output format needs at least the degrees of freedom of the input. - As a result, we end up having to distinguish "rewriter" and "full" modes in both lowering and code-emit steps, so that we can react appropriately. - Generating a GLSL `main()` also adds a lot of complexity. Right now I'm using the simplest approach, where we always output the Slang/HLSL entry point as an ordinary function (as written) and then emit a simple GLSL `main()` to call it. I generate globals for all the shader inputs/outputs (these need to be scalarized and have explicit `location`s attached), and then collect these into the `struct` types of the original parameters as needed. - This approach will start to have some major down-sides once we have to deal with "arrayed" input/output - A long-term question here is how to replace entry-point parameter types with scalarized and/or "transposed" versions, while still letting the original code work as written (including copying those inputs to temporary arrays) - Split `BlockStatementSyntaxNode` into: - `BlockStmt` which just provides a scope around a `body` statement - `SeqStmt` which just allows multiple statements to be treated as one - Change how we emit `for` loops, to deal with the case where the initialization part might expand into multiple statements - Basically `for(A;B;C) {D}` becomes `{A; for(;B;C) {D}}`, so we can handle arbitrary statements for `A` - As an additional wrinkle, when we are rewriting HLSL, we just generate `A; for(;B;C) {D}` to deal with the broken scoping there - This change is needed because the lowering pass was sometimes expanding the original initialization statement `A` into a block `{A}`. Certainly if it declared multiple variables we'd need to handle it, and this seemed the easiest way - A more significant challenge for lowering would come if/when we ever wanted to support true short-circuiting behavior for `&&` and `\|\|` - For right now I'm not changing the behavior of the "rewriter" mode, so we still have `UnparsedStmt` instances being generated, but it is clear that eventually we need to parse all input, even if we can't type-check 100% of it. This is required so that we can rewrite user code that might refer to a shader input with interface type.
2017-06-28	Store integer literals at high precision in AST	Tim Foley
	The lexer was creating an `unsigned long long` value, and then the AST was storing it in an `int`. This change makes both use a `long long`. This is obviously still a stopgap until I can get arbitrary precisions in here.
2017-06-28	Actually respect suffixes on numeric literals.	Tim Foley
	- Add logic to extract the value and suffix from a numeric literal - This duplicates some of the lexing logic, but this is hard to avoid without redundant runtime work - Note that I'm not using and stdlib string-to-number code. This should be more robust once it is working, but it is obviously error prone in the near term. The main up-sides to this are: - We can handle binary integer literals - We can handle hexadecimal floating-point literals without stdlib support - We can hypothetically support digit separators, if we ever wanted - The parser looks at the suffix characters sliced off by the lexer, and tries to pick a type to use for a literal - It uses `NULL` if there is no suffix, to avoid some nasty order dependencies where the stdlib might need to parse a number before it has seen the definition of `int` - Right now I only handle a few cases, so there may be bugs lurking here - The emit logic needs to handle the fact that a literal node in the AST might have a non-default type attached. - Right now I just quickly check for the most likely types, and emit the literal with a matching suffix. This doesn't seem robust if any source language supports a suffix for a type where a target has no corresponding suffix. In the long term some amount of casting is probably required.
2017-06-28	Rename literal tokens.	Tim Foley
	These had a typo (`Literial`), so they needed a fix eventually. I also went ahead and made things a bit more verbose (`IntegerLiteral`, `FloatingPointLiteral`) because these names don't get used often enough for the brevity to pay off.
2017-06-27	Emit global-scope parameters from imported files.	Tim Foley
	This fixes up a bug in the earlier change that provided reflection for imported parameters; I'd failed to confirm that the code generation logic can handle imported parameters correctly. The main fix was to have an `import` declaration automatically use the global-scope layout already determined, sine imported parameters will in general appear there.
2017-06-26	Fix parsing of string literals.	Tim Foley
	String literals can be used as part of attributes, but we lacked an actual AST representation for them. This change adds basic parsing for string literals, as well as emit logic for them. I also included a fix for parsing of chained right-associative operators. To test these fixes, I've re-enabled one of the HLSL tests I disabled a while back. It would be good to go through and see how many of those we can re-enable now.
2017-06-21	Emit: Add support for `while` and `do {} while` statements	Tim Foley
	These were being passed over by the emit logic because I didn't have tests that used them.
2017-06-20	Only emit each `import`ed module once.	Tim Foley
	If the user imports a module along more than one path, we need to make sure we don't emit the code twice. I handle this by keeping a set of already-emitted modules. Down the line, a more robust code generation strategy for non-"rewriter" use cases would be handling this at the per-declaration level, and this logic wouldn't really be needed.