We need this outside the constructor for the ParseException class, so
let's pull it out. mlog seemed like a good place since it's a text
formatting function, and has no dependencies.
T.Sequence is a questionable concept. The idea is to hammer out generic,
maximally forgiving APIs that operate on protocols, which is a fancy way
of saying "I don't care if you use tuples or lists". This is rarely
needed, actually, and in exchange for this fancy behavior you get free
bugs.
Specifically, `somestr` is of type `T.Sequence[str]`, and also
`somestr[0]` is another string of type you guessed it. It's ~~turtles~~
strings all the way down.
It's worth noting that trying to code for "protocols" is a broken
concept if the contents have semantic meaning, e.g. it operates on
"the install tags of this object" rather than "an iterable that supports
efficient element access".
The other way to use T.Sequence is "I don't like that T.List is
invariant, but also I don't like that T.Tuple makes you specify exact
ordering". This sort of works. In fact it probably does work as long as
you don't allow str in your sequences, which of course everyone allows
anyway.
Use of Sequence has cute side effects, such as actually passing lists
around, knowing that you are going to get a list and knowing that you
need to pass it on as a list, and then having to re-allocate as
`list(mylist)` "because the type annotations says it could be a str or
tuple".
Except it cannot be a str, because if it is then the application is
fatally flawed and logic errors occur to disastrous end user effects,
and the type annotations:
- do not enforce their promises of annotating types
- fail to live up to "minimal runtime penalties" due to all the `list()`
Shun this broken concept, by hardening the type annotations. As it turns
out, we do not actually need any of this covariance or protocol-ism for
a list of strings! The whole attempt was a slow, buggy waste of time.
+ Extend the parser to recognize the multiline f-strings, which the
documentation already implies will work.
The syntax is like:
```
x = 'hello'
y = 'world'
msg = f'''This is a multiline string.
Sending a message: '@x@ @y@'
'''
```
which produces:
```
This is a multiline string.
Sending a message: 'hello world'
```
+ Added some f-string tests cases to "62 string arithmetic" to exercise
the new behavior.
Given a meson.build with the contents:
```
t = '
'
```
We want to warn that this is bad. So we emitted this warning:
```
WARNING: Newline character in a string detected, use ''' (three single quotes) for multiline strings instead.
This will become a hard error in a future Meson release. t = ' 4 4
```
The line contents and the offset are printed as gibberish after a big
whitespace run. These are elsewhere often passed to ParseException,
which pretty-prints this, but newlines aren't an exception, merely a
warning, and mlog.warning doesn't accept numeric strings as anything
more meaningful than something to print as text.
Fix this (by wrapping it in a ParseException) to properly print:
```
meson.build:4: WARNING: Newline character in a string detected, use ''' (three single quotes) for multiline strings instead.
This will become a hard error in a future Meson release.
t = '
^
```
A backslash-escape of the last newline before a run of whitespace
leading to the indented string ending and function termination `)` does
not actually escape the entire line and make it do nothing. In fact what
it does is cause all that whitespace to be part of the preceding line,
and get printed.
Meanwhile the textwrap.dedent documentation states that lines with only
whitespace get normalized. When you *don't* mess with that final line,
dedent actually does the right thing and makes the output message end
with a single newline after the important text.
In some cases, init variables that accept None as a sentinel and
immediately overwrite with [], are migrated to dataclass field
factories. \o/
Note: dataclasses by default cannot provide eq methods, as they then
become unhashable. In the future we may wish to opt into declaring them
frozen, instead/additionally.
We have a lot of these. Some of them are harmless, if unidiomatic, such
as `if (condition)`, others are potentially dangerous `assert(...)`, as
`assert(condtion)` works as expected, but `assert(condition, message)`
will result in an assertion that never triggers, as what you're actually
asserting is `bool(tuple[2])`, which will always be true.
This didn't actually catch what it's supposed to, which is cases of:
```python
for x in dict.keys():
y = dict[x]
```
But it did catch one unnecessary use of keys(), and one case where we
were doing something in an inefficient way. I've rewritten:
```python
if name.value in [x.value for x in self.kwargs.keys() if isinstance(x, IdNode)]:
```
as
``python
if any((isinstance(x, IdNode) and name.value == x.value) for x in self.kwargs):
```
Which avoids doing two iterations, one to build the list, and a
second to do a search for name.value in said list, which does a single
short circuiting walk, as any returns as soon as one check returns True.
The arithmetic operators are now split into two groups:
* The add/sub group: +, -
* The mul/div group: *, /, %
All operators within the same group are left-associative and have equal
precedence. The mul/div group has a higher precedence than the add/sub
group, as one would expect.
Previously every operator had a different precedence and was
right-associative, which resulted in surprising behavior.
This is a potentially breaking change for projects that relied on the
old incorrect behavior.
Fixes#6870
This also fixes that the keys in ArgumentNode.kwargs are
all of the type BaseNode now. Before this commit, it was
possible that both strings and Nodes where used as keys.
Fixes PR #6166 and more specifically commit 4e460f04f3 that tried to
make sure the type of a key variable is a string but checked the type of
the value instead. Extends test common/228's limited coverage,
its only test case had (surprise) a string value. Also avoid reserved
python keyword 'dict' and potentially confusing string 'key'.
Implements #5231 for real.
* 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
* tests: extend ternary test to cover bugs
See issues #5003, #3690, and #2404
* mparser: store subdir in ternary node
Ternaries don't really need subdirs, but they can be passed into
functions that expect the type they're provided to have a
subdir. Provide it to fulful the interface.
Fixes#5003Fixes#3690Fixes#2404
The documentation states: "In other cases you can get multi-line
statements by ending the line with a \." but that seems to never have
worked.
Closes: #4720
Simplify support for alternate bases using int(..., base=0) which
auto-detects it using the standard Python syntax for numbers.
Octal numbers are useful to specify permission bits and umasks.
Binary numbers are not super useful... But considering we get them for
free, let's allow them here too.
v2: Tweak the regex so it doesn't accept a decimal number with a leading
zero, which is invalid for int(..., base=0) and would raise a ValueError
if passed around.
For now dicts are immutable, and do not expose any methods,
they however support "native" syntax such as [] lookup,
and foreach iterating, and can be printed.
Eli Schwartz