<feed xmlns='http://www.w3.org/2005/Atom'>
<title>slang.git/tests/bugs/gh-666.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>2024-03-23T17:54:01+00:00</updated>
<entry>
<title>Make `-no-mangle` option work, add `-no-hlsl-binding`. (#3817)</title>
<updated>2024-03-23T17:54:01+00:00</updated>
<author>
<name>Yong He</name>
<email>yonghe@outlook.com</email>
</author>
<published>2024-03-23T17:54:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/commit/?id=a23adc221b1ea26db3f3313226b629eb9e308b0f'/>
<id>urn:sha1:a23adc221b1ea26db3f3313226b629eb9e308b0f</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Fix error when one constant is defined equal to another (#670)</title>
<updated>2018-10-11T18:17:40+00:00</updated>
<author>
<name>Tim Foley</name>
<email>tfoleyNV@users.noreply.github.com</email>
</author>
<published>2018-10-11T18:17:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.yummers.dev/slang.git/commit/?id=13c6b69cc2601ff4764f095fb45ad9573d34ff2f'/>
<id>urn:sha1:13c6b69cc2601ff4764f095fb45ad9573d34ff2f</id>
<content type='text'>
* Fix error when one constant is defined equal to another

Fixes #666

When a user declares one constant (usually a `static const` variable) to be exactly equal to another by name:

```hlsl
static const a = 999;
static const b = a;
```

Then the IR-level representation of `b` is an `IRGlobalConstant` whose value expression is just a pointer to the definition of `a`.

The logic in `emitIRGlobalConstantInitializer()` was trying to always call `emitIRInstExpr` to emit the value of the constant as an expression, but that function only handles complex/compound expressions and not the case of simple named values (e.g., constants like `a`).

The intention is for code to call `emitIROperand()` instead, and let it decide whether to emit an expression or a named reference using its own decision-making. The `IRGlobalConstant` case really just wants to pass in the "mode" flag it uses to influence that decision-making, but shouldn't be working around it.

This change just replaces the `emitIRInstExp()` call with `emitIROpernad()` and adds a test case to confirm that this fixes the reported problem.

* Fixups for bugs in previous change

The first problem was that certain instruction ops were being special-cased to opt out of "folding" into expressions *before* we make the universal check to always fold when inside an initializer for a global constant.

The second problem is that the `emitIROperand()` logic was always putting expressions around sub-expressions, which breaks parsing when the sub-expression is an initializer list (`{...}`). This fixup is pretty much a hack, but will be something we can remove once we don't emit unncessary parentheses overall, which is a better fix.
</content>
</entry>
</feed>
