yum-mirror/slang
Making it easier to work with shaders
git clone https://git.yummers.dev/yum-mirror/slang
a508b264e
master
Slang Doc System
Slang contains a rudimentary documentation generation system. The mechanism used to mark up source is similar to doxygen. Namely
/**
... text ... (JavaDoc style)
*/
void someFunctionA() {}
/*!
.. text .. (QT style)
another line
*/
void someFunctionB() {}
/// ... text ... (Multi line)
/// another line
void someFunctionC() {}
//!... text ... (QT Multi line)
//! another line
void someFunctionD() {}
All of the above examples will add the documentation for the declaration that appears after them. Also note that this slightly diverges from doxygen in that an empty line before and after in a multi line comment is not required.
We can also document the parameters to a function similarly
/// My function
void myFunction(
/// The A parameter
int a,
/// The B parameter
int b);
If you just need a single line comment to describe something, you can place the documentation after the parameter as in
/// My function
void myFunction( int a, //< The A parameter
int b) //< The B parameter
{}
This same mechanisms work for other kinds of common situations such as with enums
/// An enum
enum AnEnum
{
Value, ///< A value
/// Another value
/// With a multi-line comment
AnotherValue,
};
Like doxygen we can also have multi line comments after a declaration for example
/// An enum
enum AnEnum
{
Value, ///< A value
///< Some more information about `Value`
/// Another value
/// With a multi-line comment
AnotherValue,
};
To actually get Slang to output documentation you can use the -doc option from the slangc command line, or pass it in as parameter to spProcessCommandLineArguments or processCommandLineArguments. The documentation is currently output by default to the same ISlangWriter stream as diagnostics. So for slangc this will generally mean the terminal/stderr.
Currently the Slang doc system does not support any of the 'advanced' doxygen documentation features. If you add documentation to a declaration it is expected to be in markdown.
Currently the only documentation style supported is a single file 'markdown' output. Future versions will support splitting into multiple files and linking between them. Also future versions may also support other documentation formats/standards.
It is possible to generate documentation for the slang core module. This can be achieved with slangc via
slangc -doc -compile-core-module
The documentation will be written to a file stdlib-doc.md.
It should be noted that it is not necessary to add markup to a declaration for the documentation system to output documentation for it. Without the markup the documentation is going to be very limited, in essence saying the declaration exists and other aspects that are available from the source. This may not be very helpful. For this reason and other reasons there is a mechanism to control the visibility of items in your source.
There are 3 visibility levels 'public', 'internal' and 'hidden'/'private'. There is a special comment that controls visibility for subsequent lines. The special comment starts with //@ as shown below.
//@ public:
void thisFunctionAppearsInDocs() {}
//@ internal:
void thisFunctionCouldAppearInInternalDocs() {}
//@ hidden:
void thisFunctionWillNotAppearInDocs() {}
1Slang Doc System 2================ 3 4Slang contains a rudimentary documentation generation system. The mechanism used to mark up source is similar to [doxygen](https://www.doxygen.nl/manual/docblocks.html). Namely 5 6``` 7/** 8... text ... (JavaDoc style) 9*/ 10void someFunctionA() {} 11 12/*! 13.. text .. (QT style) 14another line 15*/ 16void someFunctionB() {} 17 18/// ... text ... (Multi line) 19/// another line 20void someFunctionC() {} 21 22//!... text ... (QT Multi line) 23//! another line 24void someFunctionD() {} 25 26``` 27 28All of the above examples will add the documentation for the declaration that appears after them. Also note that this slightly diverges from doxygen in that an empty line before and after in a multi line comment is *not* required. 29 30We can also document the parameters to a function similarly 31 32``` 33/// My function 34void myFunction( 35/// The A parameter 36int a, 37/// The B parameter 38int b); 39``` 40 41If you just need a single line comment to describe something, you can place the documentation after the parameter as in 42 43``` 44 45/// My function 46void myFunction( int a, //< The A parameter 47int b) //< The B parameter 48{} 49``` 50 51This same mechanisms work for other kinds of common situations such as with enums 52 53``` 54/// An enum 55enum AnEnum 56{ 57Value, ///< A value 58/// Another value 59/// With a multi-line comment 60AnotherValue, 61}; 62``` 63 64Like `doxygen` we can also have multi line comments after a declaration for example 65 66``` 67/// An enum 68enum AnEnum 69{ 70Value, ///< A value 71///< Some more information about `Value` 72 73/// Another value 74/// With a multi-line comment 75AnotherValue, 76}; 77``` 78 79 80 81 82To actually get Slang to output documentation you can use the `-doc` option from the `slangc` command line, or pass it in as parameter to `spProcessCommandLineArguments` or `processCommandLineArguments`. The documentation is currently output by default to the same `ISlangWriter` stream as diagnostics. So for `slangc` this will generally mean the terminal/stderr. 83 84Currently the Slang doc system does not support any of the 'advanced' doxygen documentation features. If you add documentation to a declaration it is expected to be in [markdown](https://guides.github.com/features/mastering-markdown/). 85 86Currently the only documentation style supported is a single file 'markdown' output. Future versions will support splitting into multiple files and linking between them. Also future versions may also support other documentation formats/standards. 87 88It is possible to generate documentation for the slang core module. This can be achieved with `slangc` via 89 90``` 91slangc -doc -compile-core-module 92``` 93 94The documentation will be written to a file `stdlib-doc.md`. 95 96It should be noted that it is not necessary to add markup to a declaration for the documentation system to output documentation for it. Without the markup the documentation is going to be very limited, in essence saying the declaration exists and other aspects that are available from the source. This may not be very helpful. For this reason and other reasons there is a mechanism to control the visibility of items in your source. 97 98There are 3 visibility levels 'public', 'internal' and 'hidden'/'private'. There is a special comment that controls visibility for subsequent lines. The special comment starts with `//@` as shown below. 99 100``` 101//@ public: 102 103void thisFunctionAppearsInDocs() {} 104 105//@ internal: 106 107void thisFunctionCouldAppearInInternalDocs() {} 108 109//@ hidden: 110 111void thisFunctionWillNotAppearInDocs() {} 112``` 113 114