The interpreter takes significant amount of time to initialize
everything in project() function. We only need to extract a string from
AST, just like we do in handle_meson_version_from_ast().
Update builtin function list using the refman
python docs/genrefman.py \
-g vim \
-o data/syntax-highlighting/vim/syntax/
This also drops gettext() and find_library() from the list of builtin
functions that have been deprecated since 2016.
Changes are squashed here because test_vim_syntax_highlighting() would
validate the file against the list of builtin functions that no longer
matches the yaml documentation.
Signed-off-by: Liam Beguin <liambeguin@gmail.com>
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/
```
To take good decisions we'll need to know if we are a Rust library which
is only know after processing source files and compilers.
Note that is it not the final list of compilers, some can be added in
process_compilers_late(), but those are compilers for which we don't
have source files any way.
We will still try to load `meson_options.txt` if `meson.options` doesn't
exist. Because there are some advantages to using `meson.options` even
with older versions of meson (such as better text editor handling)
we will not warn about the existence of a `meson.options` file if a
`meson_options.txt` file or symlink also exists.
The name `meson.options` was picked instead of alternative proposals,
such as `meson_options.build` for a couple of reasons:
1. meson.options is shorter
2. While the syntax is the same, only the `option()` function may be
called in meson.options, while, it may not be called in meson.build
3. While the two files share a syntax and elementary types (strings,
arrays, etc), they have different purposes: `meson.build` declares
build targets, `meson.options` declares options. This is similar to
the difference between C's `.c` and `.h` extensions.
As an implementation detail `Interpreter.option_file` has been removed,
as it is used exactly once, in the `project()` call to read the options,
and we can just calculate it there and not store it.
Fixes: #11176
Inside of mesonbuild.ast.* we can and should import from .foobar, rather
than importing from .__init__'s re-exported version of that object.
Failing to do so results in an extremely brittle codebase where simply
changing the order of lines in __init__.py can result in ImportError.
Which adds the `use-set-for-membership` check. It's generally faster in
python to use a set with the `in` keyword, because it's a hash check
instead of a linear walk, this is especially true with strings, where
it's actually O(n^2), one loop over the container, and an inner loop of
the strings (as string comparison works by checking that `a[n] == b[n]`,
in a loop).
Also, I'm tired of complaining about this in reviews, let the tools do
it for me :)
This function can be used to add fundamental dependencies such as glib
to all build products in one fell swoop. This can be useful whenever,
due to a project's coding conventions, it is not really possible to
compile any source file without including the dependency.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Adds a new debug() function that can be used in the meson.build to
log messages to the meson-log.txt that will not be printed to stdout
when configuring the project.
Previously subprojects inherited languages already added by main
project, or any previous subproject. This change to have a list of
compilers per interpreters, which means that if a subproject does not
add 'c' language it won't be able to compile .c files any more, even if
main project added the 'c' language.
This delays processing list of compilers until the interpreter adds the
BuildTarget into its list of targets. That way the interpreter can add
missing languages instead of duplicating that logic into BuildTarget for
the cython case.
Using future annotations, type annotations become strings at runtime and
don't impact performance. This is not possible to do with T.cast though,
because it is a function argument instead of an annotation.
Quote the type argument everywhere in order to have the same effect as
future annotations. This also allows linters to better detect in some
cases that a given import is typing-only.
This replaces the absolute hack of using
```
install_subdir('nonexisting', install_dir: 'share')
```
which requires you to make sure you don't accidentally or deliberately
have a completely different directory with the same name in your source
tree that is full of files you don't want installed. It also avoids
splitting the name in two and listing them in the wrong order.
You can also set the install mode of each directory component by listing
them one at a time in order, and in fact create nested structures at
all.
Fixes#1604
Properly fixes#2904
This is the final refactoring for extracting the bultin object
logic out of Interpreterbase. I decided to do both arrays and
dicts in one go since splitting it would have been a lot more
confusing.
Another commit in my quest to rid InterpreterBase from all higher
level object processing logic.
Additionally, there is a a logic change here, since `str.join` now
uses varargs and can now accept more than one argument (and supports
list flattening).
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.