<feed xmlns='http://www.w3.org/2005/Atom'>
<title>slang.git/tests/preprocessor/import.slang.h, 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-01-26T23:30:23+00:00</updated>
<entry>
<title>Fix handling of errors in imported modules (#387)</title>
<updated>2018-01-26T23:30:23+00:00</updated>
<author>
<name>Tim Foley</name>
<email>tfoleyNV@users.noreply.github.com</email>
</author>
<published>2018-01-26T23:30:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/commit/?id=06f0effb848c6b938e03da8a61e44b3d032380e8'/>
<id>urn:sha1:06f0effb848c6b938e03da8a61e44b3d032380e8</id>
<content type='text'>
* Fix handling of errors in imported modules

- If a semantic error is detected in an imported module, then don't try to generate IR code for it

- Also, if a module (transitively) imports itself, then report that as an error
  - The way I'm checking for this is a bit hacky (I'm adding the module to the map of loaded modules, but in an "unfinished" state, and then using that unfinished state to detect the import of a module already being imported).

This isn't a 100% complete solution for any of the related problems, but it improves the user experience for the common case.

* Remove #import test.

The feature is slated to be removed, so it isn't worth fixing up this test case.
</content>
</entry>
<entry>
<title>Make `#import` work with preprocessor macros</title>
<updated>2017-06-26T19:06:54+00:00</updated>
<author>
<name>Tim Foley</name>
<email>tfoley@nvidia.com</email>
</author>
<published>2017-06-26T17:11:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/commit/?id=6e99b81c98f8c76444563d959536073befc7d8ca'/>
<id>urn:sha1:6e99b81c98f8c76444563d959536073befc7d8ca</id>
<content type='text'>
With this change, there is now a meaningful semantic difference between `__import` and `#import`.

An `__import` compiles the target file in a fresh environment, only providing it any macro definitions passed via command line or API. Any macros defined in the imported file are not made visible at the import site. One can think of an `__import` as a bit like `using namespace` in C++.

A `#import` will tokenize the input in the same preprocessor environment as the importing file, and any macros defined along the way will be visible in the parent file.
It is a *bit* like a `#include` with two big differences:

- The imported code is always parsed as Slang, and as its own module with default flags, etc. (so semantic checks are on even if we are in "rewriter" mode). It is pulled into the outer namespace just as for `__import`.

- A given file will only get `#import`ed once for a translation unit, so it behaves a bit like there is an implicit `#pragma once` in the target file
</content>
</entry>
</feed>
