hey! this is a static git repo viewer. commit diffs, file history, older commits and other revisions won't load without javascript.

you are still able to view source files on branch tips, but the experience is degraded.

yum-mirror/slang

Making it easier to work with shaders

git clone https://git.yummers.dev/yum-mirror/slang

Theresa FoleyAdd skeleton of a language reference. (#4808)e4088cd602024-08-22

renderedcode

Note: This document is a work in progress. It is both incomplete and, in many cases, inaccurate.

Lexical Structure

Source Units

A source unit comprises a sequence of zero or more characters which for purposes of this document are defined as Unicode scalars (code points).

Encoding

Implementations may accept source units stored as files on disk, buffers in memory, or any appropriate implementation-specified means. When source units are stored as byte sequences, they should be encoded using UTF-8. Implementations may support additional implemented-specified encodings.

Whitespace

Horizontal whitespace consists of space (U+0020) and horizontal tab (U+0009).

A line break consists of a line feed (U+000A), carriage return (U+000D) or a carriage return followed by a line feed (U+000D, U+000A). Line breaks are used as line separators rather than terminators; it is not necessary for a source unit to end with a line break.

Escaped Line Breaks

An escaped line break comprises a backslack (\, U+005C) follow immediately by a line break.

Comments

A comment is either a line comment or a block comment:

// a line comment
/* a block comment */

A line comment comprises two forward slashes (/, U+002F) followed by zero or more characters that do not contain a line break. A line comment extends up to, but does not include, a subsequent line break or the end of the source unit.

A block comment begins with a forward slash (/, U+002F) followed by an asterisk (*, U+0052). A block comment is terminated by the next instance of an asterisk followed by a forward slash (*/). A block comment contains all characters between where it begins and where it terminates, including any line breaks. Block comments do not nest. It is an error if a block comment that begins in a source unit is not terminated in that source unit.

Phases

Compilation of a source unit proceeds as if the following steps are executed in order:

Line numbering (for subsequent diagnostic messages) is noted based on the locations of line breaks
Escaped line breaks are eliminated. No new characters are inserted to replace them. Any new escaped line breaks introduced by this step are not eliminated.
Each comments is replaced with a single space (U+0020)
The source unit is lexed into a sequence of tokens according the lexical grammar in this chapter
The lexed sequence of tokens is preprocessed to produce a new sequence of tokens (Chapter 3)
Subsequent processing is performed on the preprocessed sequence of tokens

Identifiers

An identifier begins with an uppercase or lowercase ASCII letter (A through Z, a through z), or an underscore (_). After the first character, ASCII digits (0 through 9) may also be used in an identifier.

The identifier consistent of a single underscore (_) is reserved by the language and must not be used by programs. Otherwise, there are no fixed keywords or reserved words. Words that name a built-in language construct can also be used as user-defined identifiers and will shadow the built-in definitions in the scope of their definition.

Literals

Integer Literals

An integer literal consists of an optional radix specifier followed by digits and an optional suffix.

The radix specifier may be:

0x or 0X to specify a hexadecimal literal (radix 16)
0b or 0B to specify a binary literal (radix 2)

When no radix specifier is present a radix of 10 is used.

Octal literals (radix 8) are not supported. A 0 prefix on an integer literal does not specify an octal literal as it does in C. Implementations may warn on integer literals with a 0 prefix in case users expect C behavior.

The digits of an integer literal may include ASCII 0 through 9. In the case of a hexadecimal literal, digits may include the letters A through F (and a through f) which represent digit values of 10 through 15. It is an error for an integer literal to include a digit with a value greater than or equal to the radix. The digits of an integer literal may also include underscore (_) characters, which are ignored and have no semantic impact.

The suffix on an integer literal may be used to indicate the desired type of the literal:

A u suffix indicates the uint type
An l or ll suffix indicates the int64_t type
A ul or ull suffix indicates the uint64_t type

Floating-Point Literals

Note: This section is not yet complete.

String Literals

Note: This section is not yet complete.

Character Literals

Note: This section is not yet complete.

Operators and Punctuation

Note: This section is not yet complete.

1> Note: This document is a work in progress. It is both incomplete and, in many cases, inaccurate.
2
3Lexical Structure
4=================
5
6Source Units
7------------
8
9A _source unit_ comprises a sequence of zero or more _characters_ which for purposes of this document are defined as Unicode scalars (code points).
10
11Encoding
12--------
13
14Implementations *may* accept source units stored as files on disk, buffers in memory, or any appropriate implementation-specified means.
15When source units are stored as byte sequences, they *should* be encoded using UTF-8.
16Implementations *may* support additional implemented-specified encodings.
17
18Whitespace
19----------
20
21_Horizontal whitespace_ consists of space (U+0020) and horizontal tab (U+0009).
22
23A _line break_ consists of a line feed (U+000A), carriage return (U+000D) or a carriage return followed by a line feed (U+000D, U+000A).
24Line breaks are used as line separators rather than terminators; it is not necessary for a source unit to end with a line break.
25
26Escaped Line Breaks
27-------------------
28
29An _escaped line break_ comprises a backslack (`\`, U+005C) follow immediately by a line break.
30
31Comments
32--------
33
34A _comment_ is either a line comment or a block comment:
35
36```hlsl
37// a line comment
38/* a block comment */
39```
40
41A _line comment_ comprises two forward slashes (`/`, U+002F) followed by zero or more characters that do not contain a line break.
42A line comment extends up to, but does not include, a subsequent line break or the end of the source unit.
43
44A _block comment_ begins with a forward slash (`/`, U+002F) followed by an asterisk (`*`, U+0052). 
45A block comment is terminated by the next instance of an asterisk followed by a forward slash (`*/`).
46A block comment contains all characters between where it begins and where it terminates, including any line breaks.
47Block comments do not nest.
48It is an error if a block comment that begins in a source unit is not terminated in that source unit.
49
50Phases
51------
52
53Compilation of a source unit proceeds _as if_ the following steps are executed in order:
54
551. Line numbering (for subsequent diagnostic messages) is noted based on the locations of line breaks
56
572. Escaped line breaks are eliminated. No new characters are inserted to replace them. Any new escaped line breaks introduced by this step are not eliminated.
58
593. Each comments is replaced with a single space (U+0020)
60
614. The source unit is _lexed_ into a sequence of tokens according the lexical grammar in this chapter
62
635. The lexed sequence of tokens is _preprocessed_ to produce a new sequence of tokens (Chapter 3)
64
656. Subsequent processing is performed on the preprocessed sequence of tokens
66
67Identifiers
68-----------
69
70An _identifier_ begins with an uppercase or lowercase ASCII letter (`A` through `Z`, `a` through `z`), or an underscore (`_`).
71After the first character, ASCII digits (`0` through `9`) may also be used in an identifier.
72
73The identifier consistent of a single underscore (`_`) is reserved by the language and must not be used by programs.
74Otherwise, there are no fixed keywords or reserved words.
75Words that name a built-in language construct can also be used as user-defined identifiers and will shadow the built-in definitions in the scope of their definition.
76
77Literals
78--------
79
80### Integer Literals
81
82An _integer literal_ consists of an optional radix specifier followed by digits and an optional suffix.
83
84The _radix specifier_ may be:
85
86* `0x` or `0X` to specify a hexadecimal literal (radix 16)
87* `0b` or `0B` to specify a binary literal (radix 2)
88
89When no radix specifier is present a radix of 10 is used.
90
91Octal literals (radix 8) are not supported.
92A `0` prefix on an integer literal does *not* specify an octal literal as it does in C.
93Implementations *may* warn on integer literals with a `0` prefix in case users expect C behavior.
94
95The _digits_ of an integer literal may include ASCII `0` through `9`.
96In the case of a hexadecimal literal, digits may include the letters `A` through `F` (and `a` through `f`) which represent digit values of 10 through 15.
97It is an error for an integer literal to include a digit with a value greater than or equal to the radix.
98The digits of an integer literal may also include underscore (`_`) characters, which are ignored and have no semantic impact.
99
100The _suffix_ on an integer literal may be used to indicate the desired type of the literal:
101
102* A `u` suffix indicates the `uint` type
103* An `l` or `ll` suffix indicates the `int64_t` type
104* A `ul` or `ull` suffix indicates the `uint64_t` type
105
106### Floating-Point Literals
107
108> Note: This section is not yet complete.
109
110### String Literals
111
112> Note: This section is not yet complete.
113
114### Character Literals
115
116> Note: This section is not yet complete.
117
118Operators and Punctuation
119-------------------------
120
121> Note: This section is not yet complete.