FIXME: another approach would be to consider cont_eol as comment (i.e.
add backslash and whitespaces to the comment regex). In both cases it
works until we want to parse comments separately.
TODO?: handle eol_cont inside a string (to split long string without
breaking lines). Probably a bad idea and better to simply join a
multiline string.
Performed using https://github.com/ilevkivskyi/com2ann
This has no actual effect on the codebase as type checkers (still)
support both and negligible effect on runtime performance since
__future__ annotations ameliorates that. Technically, the bytecode would
be bigger for non function-local annotations, of which we have many
either way.
So if it doesn't really matter, why do a large-scale refactor? Simple:
because people keep wanting to, but it's getting nickle-and-dimed. If
we're going to do this we might as well do it consistently in one shot,
using tooling that guarantees repeatability and correctness.
Repeat with:
```
com2ann mesonbuild/
```
- Include BaseNode position in hash methods, integer is the most
straightforward way of differentiating nodes.
- Exclude non hashable fields from hash method.
- Avoid using default values in BaseNode that way subclasses can have
fields wihtout default value without repeating init=False.
- Nodes that does not add fields does not need `@dataclass`.
- Make all node types hashable because they can be used for feature_key
in FeatureCheckBase.use().
- Remove unused type annotations
Surprisingly enough we need to do this twice. In some cases
(failing-meson/72 triggers this) we can error out after parsing the
codeblock, but without getting the expected eof.
We need to catch both exceptions as either one can interrupt the built
codeblock object.
Co-authored-by: Xavier Claessens <xavier.claessens@collabora.com>
This reverts commit 348248f0a1.
The rules were relaxed in commit ccc4ce28cc
to permit this, so it's never possible to raise this exception anymore.
But that commit was incomplete, and didn't remove the now-useless
infrastructure for exception handling.
The test needed to test this was always broken, and then removed in
commit 465ef856ac, and still this useless
try/except persisted.
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.
Charles Brunet