| lib.rs |
|
5686 |
| parse_tests.rs |
lol\nfoo\n |
80933 |
| parser.rs |
GLSL parsing.
This module gives you several functions and types to deal with GLSL parsing, transforming an
input source into an AST. The AST is defined in the [`syntax`] module.
You want to use the [`Parse`]’s methods to get starting with parsing and pattern match on
the resulting [`Result`]. In case of an error, you can inspect the content of the [`ParseError`]
object in the `Err` variant.
[`Parse`]: crate::parser::Parse
[`ParseError`]: crate::parser::ParseError |
4531 |
| parsers |
|
|
| parsers.rs |
GLSL parsers.
The more general parser is `translation_unit`, that recognizes the most external form of a GLSL
source (a shader, basically).
Other parsers are exported if you want more control on how you want to parse your source. |
58769 |
| syntax.rs |
GLSL abstract syntax tree and grammar.
This module exports all the grammar syntax that defines GLSL. You’ll be handling ASTs
representing your GLSL source.
The most external form of a GLSL parsed AST is [`TranslationUnit`] (a shader). Some parts of the
tree are *boxed*. This is due to two facts:
- Recursion is used, hence we need a way to give our types a static size.
- Because of some very deep variants, runtime size would explode if no indirection weren’t
in place.
The types are commented so feel free to inspect each of theme. As a starter, you should read
the documentation of [`Expr`], [`FunctionDefinition`], [`Statement`] and [`TranslationUnit`].
[`Statement`]: crate::syntax::Statement
[`TranslationUnit`]: crate::syntax::TranslationUnit
[`Expr`]: crate::syntax::Expr
[`FunctionDefinition`]: crate::syntax::FunctionDefinition |
31744 |
| transpiler |
|
|
| visitor.rs |
AST visitors (i.e. on-the-fly mutation at different places in the AST).
Visitors are mutable objects that can mutate parts of an AST while traversing it. You can see
them as flexible mutations taking place on *patterns* representing your AST – they get called
everytime an interesting node gets visited. Because of their mutable nature, you can accumulate
a state as you traverse the AST and implement exotic filtering.
Visitors must implement the [`Visitor`] trait in order to be usable.
In order to visit any part of an AST (from its very top root or from any part of it), you must
use the [`Host`] interface, that provides the [`Host::visit`] function.
For instance, we can imagine visiting an AST to count how many variables are declared:
```
use glsl::syntax::{CompoundStatement, Expr, SingleDeclaration, Statement, TypeSpecifierNonArray};
use glsl::visitor::{Host, Visit, Visitor};
use std::iter::FromIterator;
let decl0 = Statement::declare_var(
TypeSpecifierNonArray::Float,
"x",
None,
Some(Expr::from(3.14).into())
);
let decl1 = Statement::declare_var(
TypeSpecifierNonArray::Int,
"y",
None,
None
);
let decl2 = Statement::declare_var(
TypeSpecifierNonArray::Vec4,
"z",
None,
None
);
let compound = CompoundStatement::from_iter(vec![decl0, decl1, decl2]);
// our visitor that will count the number of variables it saw
struct Counter {
var_nb: usize
}
impl Visitor for Counter {
// we are only interested in single declaration with a name
fn visit_single_declaration(&mut self, declaration: &SingleDeclaration) -> Visit {
if declaration.name.is_some() {
self.var_nb += 1;
}
// do not go deeper
Visit::Parent
}
}
let mut counter = Counter { var_nb: 0 };
compound.visit(&mut counter);
assert_eq!(counter.var_nb, 3);
```
[`Host`]: crate::visitor::Host
[`Host::visit`]: crate::visitor::Host::visit
[`Visitor`]: crate::visitor::Visitor |
41644 |