<feed xmlns='http://www.w3.org/2005/Atom'>
<title>slang.git/tests/front-end/interface.slang, branch master</title>
<subtitle>Making it easier to work with shaders</subtitle>
<id>https://git.yummers.dev/slang.git/atom?h=master</id>
<link rel='self' href='https://git.yummers.dev/slang.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/'/>
<updated>2018-02-03T15:30:54+00:00</updated>
<entry>
<title>Remove non-IR codegen paths (#398)</title>
<updated>2018-02-03T15:30:54+00:00</updated>
<author>
<name>Tim Foley</name>
<email>tfoleyNV@users.noreply.github.com</email>
</author>
<published>2018-02-03T15:30:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/commit/?id=662f43fff6721c6cd013a8f1b2639c2e29fe6be3'/>
<id>urn:sha1:662f43fff6721c6cd013a8f1b2639c2e29fe6be3</id>
<content type='text'>
The basic change is simple: remove support for all code generation paths other than the IR.
There is a lot of vestigial code left, but the main logic in `ast-legalize.*` is gone.

Doing this breaks a *lot* of tests, for various reasons:

- We can no longer guarantee exactly matching DXBC or SPIR-V output after things pass through out IR

- Many builtins don't have matching versions defined for GLSL output via IR (even when they had versions defined via the earlier approach that worked with the AST)

- A lot of code creates intermediate values of opaque types in the IR, which turn into opaque-type temporaries that aren't allowed (this breaks many GLSL tests, but also some HLSL)

I implemented some small fixes for issues that I could get working in the time I had, but most of the above are larger than made sense to fix in this commit.

For now I'm disabling the tests that cause problems, but we will need to make a concerted effort to get things working on this new substrate if we are going to make good on our goals.</content>
</entry>
<entry>
<title>Add basic support for `interface` declarations</title>
<updated>2017-06-15T19:42:52+00:00</updated>
<author>
<name>Tim Foley</name>
<email>tfoley@nvidia.com</email>
</author>
<published>2017-06-15T18:16:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/commit/?id=367edf757aff609b72de48732113ea756d878f52'/>
<id>urn:sha1:367edf757aff609b72de48732113ea756d878f52</id>
<content type='text'>
- Add a test case for `interface` declarations and the exected implicit type conversion rules around them

- Rename exising "trait" declaration kind to "interface"
  - There was already basic syntax for `__trait` declarations, and a bunch of related machinery.
  - Not all of it worked as needed, but it was clearly a start at solving the problem

- Change `InterfaceConformanceDecl` to a more general `InheritanceDecl` that covers inheritance from any type expression (leave it to other code to validate the cases that should be allowed)

- Instead of keeping a raw `bases` array on interface/trait declarations, turn all inheritance clauses into `IheritanceDecl` members

- Add support for inheritance clause on `struct` types

- Remove the `__conforms` syntax only used in the stdlib, in favor of conentional `: Base` style syntax already in place for aggregate types

- Make sure that the parser pushes a new scope around he member declarations of an aggregate type, so that lookup in member functions will correctly find members of the enclosing type

- In `TryCoerceImpl`, allow a type that conforms to an interface to be implicitly conveted to the corresponding interface type.

This leaves out a lot of major functionality:

- There is no validation that a type provides all the members it is supposed to as part of fulfilling a claimed interface conformance

- The lookup process needs to deal with inherited members at some point.
  - We can avoid this for now if we don't allow inheritance for concrete types
  - When it comes time to handle it, it *might* be possible to implement by considering an `InheritanceDecl` to be, conceptually, a member of the inherited type, with a `__transparent` modifier

- The lookup rules member functions do *not* deal with a lot of stuff:
  - There is no `this` expression right now
  - The semantic checker does not rewrite `foo` to `this.foo`, so downstream stages aren't going to get things in a clean format
  - There is no handling of mutability currently
    - The right answer there is probably to make member functions on `struct` types non-mutating by default, and add a qualifier to opt in to mutability. I believe this is actually what the OOP syntax in HLSL did way back when.
  - There is no handling of `static` members, and thus no checking to make sure that non-static members aren't referenced in static functions

- None of this affects down-stream code generation right now, so it probably won't actually produce anything valid.
  - This is where we start needing a suitable IR to use for lowering, to manage the complexity.
</content>
</entry>
</feed>
