This function has a pretty unique name, and a simple grep shows that it
is only ever called as:
```
add_comment(PbxComment('...........'))
```
It doesn't need to include logic such as handling str. Moreover it looks
like that handling was broken anyway... it handled the case where
comment is type str, by constructing a new PbxComment(str) instead of
PbxComment(comment), a condition that cannot ever be valid (and crashed
due to other assertions).
Fixes:
mesonbuild/backend/xcodebackend.py:148:42: error: Argument 1 to "PbxComment" has incompatible type "type[str]"; expected "str" [arg-type]
We are going to truncate it down below with int() anyway, no need to
carry extra precision. And mypy complains if the type changes between
float and int.
The new splitlines method on str is intended to replace usage of
fs.read('whatever').strip().split('\n').
The problem with the .strip().split() approach is that it doesn't have a
way to represent empty lists (an empty string becomes a list with one
empty string, not an empty list), and it doesn't handle Windows-style
line endings.
When meson is installed as editable, setuptools adds
`__editable___meson_1_0_99_finder` to the list. This contains the string
"meson" which isn't really accurate to what we want, which is modules
that are part of the `mesonbuild.*` namespace.
an int only accepts operations on other ints, just like other primitive
types only accept operations on values of the same type.
But due to using isinstance in baseobjects "operator_call", an int
primitive allowed operations on a bool, even though reversing the
operator and having a bool perform operations on an int, would fail with
a type error.
Really, we should fail with a type error in both directions. But for
stability reasons, make this a loud warning and break --fatal-meson-warnings
builds.
This is useful for totally terrible stuff that we really dislike, but
for some reason we are afraid to just use `mlog.deprecation()` and
unconditionally tell people so.
Apparently this is because it is totally absolutely vital that, when
telling people something is so broken they should never ever ever use it
no matter what, ever... we can't actually tell them that unless they
bump the minimum version of Meson, because that's our standard way of
introducing a **version number** to tell them when we first started
warning about this.
Sigh. We really want to warn people if they are doing totally broken
stuff no matter what version of Meson they support, because it's not
like fixing the thing that never worked is going to suddenly break old
versions of meson.
So. Here's some new functionality that always warns you, but also tells
you when we started warning.
The version output scraping for identifying strings checked for "IFORT"
in parentheses after the executable name, which is probably a mistake by
Intel. Current versions of ifx have "IFX" in parentheses there.
Detect both.
Fixes#11873
When a project targets a dev version of Meson (e.g. 1.1.99) for
experimenting, this allows to use:
project(..., meson_version: '>=1.2.0')
It avoids getting warnings when using FeatureNew for features introduced
in 1.2.0.
Specifically, when those files can be created by a build rule with one
version of meson.build, and created as e.g. a shared_library alias
symlink in another version of meson.build, the cleandead command will
delete important files just because they don't happen to be created by
ninja itself.
Work around this by making a dummy rule that exists solely to insert the
files into the build graph to trick ninja into not deleting them.
Closes#11861
If py2 is not found *and* the compiler is MSVC, we didn't take into
account that py2 is not found. This also meant that we didn't take into
account the expected count when it *is* found, because the python module
has a better finder than just "is the binary on PATH".
In commit 89146e84c9 we added some
complicated code to verify the llvm framework's "combination" matrix
lookup. It expects to find llvm with both cmake and config-tool, with
the same version. But the sanity check is wonky -- it checks that both
have the same found status, instead, so if both are not found then we
proceed to try to convert the string "unknown" to a mapping of semver
integers, and this is guaranteed to fail.
This can happen for example if the system llvm exists in the general
case, but actual modules cannot be found because the system llvm does
not distribute static modules. For example, this is the case on Gentoo.
Abort more obviously by just insisting that both be found. If they
aren't both found, then investigative efforts know to look at why they
weren't found.
- 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
Eli Schwartz
Martin Dørum
Alyssa Ross
Jussi Pakkanen
Charles Brunet
L. E. Segovia
Xavier Claessens
Sébastien Villemot
Karol Herbst
Dylan Baker
Matthew Waters
Tristan Partin
Nathan Kidd