| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This documents the bool methods to_int and to_string implemented in
[1].
[1]: https://github.com/mesonbuild/meson/blob/a9e9b7c7501a3c8a5984a93879d1f309bf8c72aa/mesonbuild/interpreterbase.py#L1109
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Someone on IRC was confused by this paragraph.
|
|
This method aims to offer a simple way to 'substring'
an existing string with start and end values.
|
|
|
|
|
|
Also document that line continuation didn't work before 0.50.
90c9b868b20b11bb089fc5e0c634d5ed76fea0cb fixed it.
|
|
* WIP: Document formal Meson grammar
* Various little fixes [skip ci]
1) Add missing logical_not_expr
2) 'in' and 'not in' are valid relational operators at least for dicts
3) dictionary keys can be expressions, but kwarg names cannot
4) typo logical_end_expression -> logical_and_expression
5) Make jump statements only allowed inside an iteration statement
* Rework EBNF style [skip ci]
As there is no good order for the productions, just go alphabetically.
The EBNF style was changed to match the one the Python lark project
uses, that is colons for productions and terminals enclosed in double
quotes.
* Add missing production for unary operators [skip ci]
* Add production for multiline strings [skip ci]
* Properly define terminal symbols [skip ci]
Depending on the EBNF flavor, regex can be used to describe the terminal
symbols. Lark allows this, and as it was mentioned as a possible user of
this grammar, let's follow its flavor here. Most regexes used are easily
human-readable, and we can always add comments to more complicated ones.
* Small changes to which expressions can be used where [skip ci]
Let the grammar be very general. The type system then has to check, that
the used expression really evaluates to the correct type. Even if we
know today that assignment expressions always evaluate to None (and can
therefore only be used as a toplevel expression in an expression
statement), this needn't be the case forever. So this way, the grammar
stays stable even if such changes were made.
* Rework function argument list production [skip ci]
* Be more verbose for production names [skip ci]
Rename expr -> expression, stmt -> statement, op -> operator, program ->
build_definition. Also adjust some list productions.
* Add paragraph about syntax stability promises [skip ci]
|
|
The only restriction is keys must be string after evaluation. This fix
various inconsistencies.
|
|
|
|
|
|
|
|
|
|
* docs: document unrecognized escape sequence behaviour [skip ci]
Document that unrecognized escape sequence behaviour is like python, not
C.
* Don't try to decode invalid hex escape sequences
Don't try to decode escape sequences which should contain a sequence of
hex digits, but don't, throwing a python exception. These will treated
literally instead.
* Extend test case to cover invalid escape sequences
|
|
This comes up now and again when people try do do something like:
meson.build:
```meson
my_sources = ['foo.c']
subdir('subdir')
executable('foo', my_sources)
```
subdir/meson.build:
```meson
my_sources += ['bar.c']
```
|
|
|
|
|
|
The "if" statement only covers a small set of the possible ways in
which conditionals can be written, since it leaves the use of
"and", "or" and "not" to the "Logical Operations" section. However,
this is likely to be of interest to those reading about "if" statments,
so move the "logical operations" section up to immediately follow it.
This change also puts in the use of the "!=" operator in the example
to widen the variety of combinations shown.
|
|
|
|
Also add a release notes snippet for it.
|
|
|
|
|
|
|
|
Fixes #3169
|
|
|
|
In CommonMark, there are no backslash escapes in code spans, so only two backslashes in the source document are necessary to produce two backslashes in the output document.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes #1870
|
|
|
|
Fix variable name
|
|
This allows us to more easily have the documentation in sync with
the source code as people will have to document new features etc
right at the time where they implement it.
|
