-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specify the grammar formulations for attributes #65
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -124,4 +124,65 @@ Below are a few more examples of C++ attributes that we could support: | |
} | ||
} | ||
``` | ||
## Detailed design | ||
|
||
The simplest explanation of this feature is supporting C++11 attribute syntax on | ||
all shared grammar elements between HLSL and C++. This spec attempts to detail | ||
some of the grammar and parsing implications and will specify the process by | ||
which existing attributes will convert to C++ attributes. | ||
### Attribute Parsing | ||
|
||
This proposal introduces new grammar formulations for parsing attributes | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd probably drop the word "new" - "introduces grammar formulations" is clear |
||
matching some formulations from C++ `dcl.attr.grammar`. Specifically: | ||
|
||
```ebnf | ||
attribute-specifier-seq: [ attribute-specifier-seq ], attribute-specifier | ||
attribute-specifier: "[" , "[" , attribute-list , "]" , "]" | ||
attribute-list: [ attribute ] || | ||
attribute-list , "," , [attribute] || | ||
{ attribute } || | ||
attribute-list , "," , { attribute } | ||
attribute: attribute-token , [attribute-argument-clause] | ||
attribute-token: identifier || | ||
attribute-scoped-token | ||
attribute-scoped-token: attribute-namespace , "::" , identifier | ||
attribute-namespace: identifier | ||
attribute-argument-clause: "(" , balanced-token-seq , ")" | ||
balanced-token-seq: [ balanced-token ] || | ||
balanced-token-seq , balanced-token | ||
balanced-token: "(" , balanced-token-seq , ")" | ||
"[" , balanced-token-seq , "]" | ||
"{" , balanced-token-seq , "}" | ||
``` | ||
|
||
In contrast to existing HLSL annotations and Microsoft-style attributes, these | ||
attribute identifiers are case-sensitive `identifier` tokens. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is probably clear enough from context and I'm just being pedantic, but "attribute identifiers are case-sensitive Maybe:
|
||
|
||
|
||
#### Statements | ||
|
||
```ebnf | ||
statement: [ attribute-specifier-seq ] , expression-statement || | ||
[ attribute-specifier-seq ] , compound-statement || | ||
[ attribute-specifier-seq ] , selection-statement || | ||
[ attribute-specifier-seq ] , iteration-statement || | ||
[ attribute-specifier-seq ] , jump-statement || | ||
declaration-statement | ||
labeled-statement | ||
labeled-statement: [ attribute-specifier-seq ] , "case" , constant-expression , ":" , statement | ||
[ attribute-specifier-seq ] , "default" , ":" , statement | ||
``` | ||
|
||
#### Declarations | ||
|
||
The `attribute-specifier-seq` element supports annotating type declarations. The | ||
following grammar formulations are valid: | ||
|
||
```ebnf | ||
class-key: "class" || "struct" | ||
class-declaration: class-key , attribute-specifier-seq , identifier | ||
|
||
alias-declaration: "using" , identifier , [ attribute-specifier-seq ] , "=" , type-id , ";" | ||
``` | ||
|
||
<!-- {% endraw %} --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Best to add a blank line before the section header for the benefit of those reading the markdown directly (I don't think it makes a difference in the rendered doc)