Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge in changes included in Meson 1.5.2 #15

Merged
merged 169 commits into from
Oct 14, 2024

Conversation

rgommers
Copy link
Member

@rgommers rgommers commented Jun 25, 2024

Updates from 1.4.99 to 1.5.2 + BLAS/SIMD feature additions.

rgommers and others added 30 commits May 19, 2024 11:36
Emscripten version numbers are unrelated to Clang version numbers,
so it is necessary to change the version checks for `c_std=c17` & co.
Without that, no project that defaults to C17 or newer will build with
Emscripten.

See pyodide/pyodide#4762 for more
context. Also note that this bug caused defaulting to C17 in
scikit-learn to be reverted (scikit-learn#29015), and it may be a
problem for SciPy 1.14.0 too since that release will upgrade from C99
to C17.

Co-authored-by: Loic Esteve <loic.esteve@ymail.com>
We cover every case as if/elif/elif. mypy can handle this fine, but
pylint doesn't do control flow or type checking and thinks in the
missing else case, the variable might not be defined.

For mypy as well, doing this instance check is unnecessary as it can be
inferred. So just micro-optimize the check and allow pylint to safely
analyze the logic.
It does no control flow analysis, and upgrading to pylint 3.2.0 produced
many incorrect warnings.

Also ignore contextmanager-generator-missing-cleanup for now. It has FP
when there is no code after a yield (and thus no cleanup needs to be
handled), which is what we do. Currently under discussion upstream:
pylint-dev/pylint#9625
…f conditional

We do:

```
if is_thing:
    assignme = value

if_is_thing:
    ...
else:
    assignme = []
```

It is always defined on both sides, but there was no particular reason
we had to assign it in the later copy. pylint reported it as a false
positive, and it may prove confusing in general, and it's harmless to
move, so do so.
A bare return at the end of a function doesn't do anything. And in the
case of a try/except, it's really just an elaborate "pass" anyway.
* Previously, cuda would just plainly prepend `-l` to the libname.
* By relying on the host compiler to find libraries, we now get
  more subtle failures, such as CUDA modules not being found
  anymore.
* We need to simplify these CUDA modules when nvcc is used for
  linking, since this may have side-effects from the cuda toolchain.

Closes: mesonbuild#13240
This reverts commit aee9415.

The commit being reverted breaks compilation of a major Meson consumer
(Mesa). As a result, various distros are either pinning to <1.4.0 (before
the commit) or performing this same revert downstream.

Fixing a regression takes priority, so let's revert.

Fixes: mesonbuild#12973
…around

Clang is such a great compiler! Not.

Compilers have enhanced diagnostics for some kinds of "well known"
undeclared identifiers, telling you exactly which header you might have
forgotten to include. The reason why clang needs an option GCC doesn't
need is because clang's fixit suggestions, unlike GCC's actually
*changes the type of the error*, as a result of a fixit of all things.

After the fixit suggestion grants this error the right to be ignored,
we start having to add clang-specific options.

Follow-up to mesonbuild#9140

Upstream clang bug, which appears to be going nowhere:
llvm/llvm-project#33905
`configure_file` kwarg `copy` runs at configure time, whereas
`fs.copyfile` runs at build time. Both have use cases, so this
undeprecates the `configure_file` version.

Fixes: mesonbuild#12792
The master branch isn't in experimental state anymore.
Arch profile.d scripts were converted to use an appending function that
disappears when /etc/profile exits, and overall are simply not suitable
-- any more -- for sourcing individually.

(I will freely admit I'm not really sure what the overall goal of
refraining from sourcing /etc/profile itself is. Arguably it's kind of
misuse of the profile...)

This silently broke the cuda tests, which never ran because the cuda
compiler was not detected as available.

While we are at it, I guess we can convert gentoo to use the same trick
of appending it in install.sh
See mesonbuild#6269 for the discussion.

Co-authored-by: Eli Schwartz <eschwartz93@gmail.com>
Signed-off-by: Filipe Laíns <lains@riseup.net>
This will allow for generating project files more specific to certain
versions of Xcode without breaking compatibility.
Some settings require "objectVersion" to be set to a certain value or
Xcode will not use it. To fix this, we set it to the highest possible
value, determined by the detected version of Xcode. We also set
"compatibilityVersion", but mainly so it lines up with "objectVersion".

At the same time, we should not be generating Xcode 3.2-compatible
projects by default anyway.
This was removed on Xcode 9, so only generate it for Xcode 8.3.3
and lower.
It started failing CI as soon as the default shifted to 1.78. Something
is broken and it prevents running stable CI. Tracking issue opened.

We pin the version because that is the same way we handle CI for linux
-- with the exception that Linux CI can upgrade itself as soon as we
fix issues causing the CI Image Builder to jam itself, whereas
unfortunately Windows will need to be manually unpinned, but such is
life as a Windows supporter.

Bug: mesonbuild#13236
dcbaker and others added 22 commits September 15, 2024 22:59
Which happens when a .editorconfig is in a subdirectory, not the root.
In this case we need Set the fallback value to `False`, which is what
editorconfig expects.

Closes: mesonbuild#13568
(cherry picked from commit 18f4a05)
Fixes mesonbuild#13508

- Fix indentation of comments in arrays
- Fix indentation of comments in dicts
- Fix indentation of comments in if clauses
- Fix indentation of comments in foreach clauses

(cherry picked from commit d9ba422)
The flag was only introduced in ld 224.1, as mentioned in the initial PR
mesonbuild#13291.

Resolves mesonbuild#13543

(cherry picked from commit 7280639)
Now it will generate a diff of the expected value and what it actually
got

(cherry picked from commit ab3cfc2)
The following is valid meson:
```meson
a = '''This string can't be simplified'''
```
which cannot be simplified because of the `'` in it, as
```meson
a = 'This string can't be simplified'
```
Is invalid.

Potentially we could convert that with escapes, but it seems reasonable
to me to leave this, since it may be desirable to not have lots of
escapes in a string. `'''I can't believe it's her's!'''` is much more
readable than `'I can\'t believe it\'s her\'s!'`, for example.

Closes: mesonbuild#13564
(cherry picked from commit df70680)
…value

I ran into this with `option = true;` (note the trailing `;`). Now we
provide a nicer message instead of an uncaught Python backtrace.

Closes: mesonbuild#13565
(cherry picked from commit 1e6e4c8)
Originally from here:

https: //bugs.debian.org/cgi-bin/bugreport.cgi?bug=1080463
(cherry picked from commit 3bb3d57)
If kwargs_force_multiline is enabled, an ArgumentNode in a kwarg value can
already be marked multiline by the time we notice that the line needs to
be broken for length.  Ensure we still break the line in this case.

Fixes: mesonbuild#13512
(cherry picked from commit 6d92547)
The zlib symbols may not be of type 'T' but rather e.g. 'D' -- instead,
tell nm to emit the POSIX format and also to only emit defined symbols,
not undefined ones. Then we just check if the symbol is listed at all,
regardless of type.

We already depend on -U elsewhere (e.g symbolextractor). There's no real
replacement for it, sadly. It's also buggy in some versions of nm, so we
check both its long and short options.

Bug: https://bugs.gentoo.org/938259
(cherry picked from commit 83f8de5)
- detect unknown config keys in format config
- add test for detection of invalid config values
- detect invalid .editorconfig values

Fixes mesonbuild#13569

(cherry picked from commit d3ef02b)
…_members()

Otherwise, `CFLAGS='-Wall -Werror' meson build` can fail detection:

          void bar(void) {
              struct stat foo;
              foo.st_mtim.tv_nsec;

          }
  -----------
  Command line: `cc ./project/build/meson-private/tmpqz_gi65d/testfile.c -o ./project/build/meson-private/tmpqz_gi65d/output.obj -c -O3 -Werror -Wall -D_FILE_OFFSET_BITS=64 -O0 -std=gnu99` -> 1
  stderr:
  ./project/build/meson-private/tmpqz_gi65d/testfile.c: In function 'bar':
  ./project/build/meson-private/tmpqz_gi65d/testfile.c:45:24: error: statement with no effect [-Werror=unused-value]
     45 |             foo.st_mtim.tv_nsec;
        |             ~~~~~~~~~~~^~~~~~~~
  cc1: all warnings being treated as errors

(cherry picked from commit a22a50a)
…_type()

Otherwise, `CFLAGS='-Wall -Werror' meson build` can fail detection:

  Running compile:
  Working directory:  ./project/build/meson-private/tmpk86bgc04
  Code:
   #include <sys/types.h>
          void bar(void) {
              sizeof(loff_t);
          }
  -----------
  Command line: `cc ./project/build/meson-private/tmpk86bgc04/testfile.c -o ./project/build/meson-private/tmpk86bgc04/output.obj -c -Werror -Wall -D_FILE_OFFSET_BITS=64 -O0 -std=gnu99` -> 1
  stderr:
  ./project/build/meson-private/tmpk86bgc04/testfile.c: In function 'bar':
  ./project/build/meson-private/tmpk86bgc04/testfile.c:3:13: error: statement with no effect [-Werror=unused-value]
      3 |             sizeof(loff_t);
        |             ^~~~~~
  cc1: all warnings being treated as errors
  -----------
  Checking for type "loff_t" : NO

(cherry picked from commit fa8bd93)
If a user imports a module and invokes a method on it,
a raw Python exception is raised to the user. This commit
adds a check to ensure that in this case an appropriate
exception is raised instead.

A test has been added to ensure that this exception is
in fact raised on offending code.

Fixes: mesonbuild#11393, mesonbuild#5134
(cherry picked from commit 74dd77e)
A common, and challenging, issue in CI runners is debugging issues when
you know the information you want to check, but it's in the log file
which you don't have because remote CI machines.

There are various edge cases where this is especially hard to solve,
such as inside of `pip install` where the build directory with the log
file is automatically cleaned up. But it's never really *easy* when you
don't expect it, and the best case scenario is your iteration time gets
cut in half as you hurriedly go add some `cat`s to your CI scripts.

Meson can, at least sometimes, detect platforms where text can be
emitted inside of "folds", which are auto-collapsed and don't obscure
the general output, but when clicked will expand the logfile contents.
Hook this up.

We start off with a Github Actions implementation. We had some internal
code used by our own project tests runner, which can be utilized.

Also permit forcing it via an environment variable, in case
autodetection fails and you just want to force *something*, especially
when meson is called a couple layers deep inside some other tool.

(cherry picked from commit 2b80d4c)
They have recently upgraded to libgcrypt 1.11 and it has inherited the
gpg suite migration to pkg-config.

(cherry picked from commit 21eda4d)
We always pass the string value of the mode to determine_args, which
causes the check on the mode argument inside determine_args to always
evaluate to false.

Fix this by passing the mode itself, not its value.

(cherry picked from commit 9cb9ad8)
…error

When `meson dist` fails with the error:

```
Dist currently only works with Git or Mercurial repos
```

It is sometimes inaccurate, since a git repo may exist but be
nonfunctional. Offer some better guidance in that case.

Fixes: mesonbuild#10866
(cherry picked from commit 81c5088)
Rust-analyzer relies on sysroot to discover its proc-macro server [1] which is
typically installed at <sysroot>/libexec/rust-analyzer-proc-macro-srv. When
used with rust-project.json, rust-analyzer expects the json file to specify
sysroot and fails to launch the proc-macro server otherwise.

So add sysroot to the meson-generated rust-project.json and point it to the
sysroot of the detected rustc compiler.

[1] https://github.com/rust-lang/rust-analyzer/blob/2024-09-16/crates/project-model/src/sysroot.rs#L175

Signed-off-by: Junjie Mao <junjie.mao@hotmail.com>
(cherry picked from commit e5d03f5)
https://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html

GNU Gettext defines a feature, whereby for translation purposes, if
LC_ALL / LANG are *not* set to C, but rather define an active
translation, the LANGUAGE variable can be used to specify fallback
languages in a colon-separated list wherein the first option is the
primary language and the rest are fallbacks.

CPython, instead, checks the LANGUAGE variable first, and the first
variable that has a non-null value is treated as the canonical language
specification, splitted, and iterated over. LC_ALL=C is therefore
totally ignored, which is a major problem, and the variables aren't
checked for consistency, which is a less major problem.

GNU libc documents the same behavior CPython does -- which is broken as
it makes LC_ALL=C useless.

POSIX issue 8 standardizes on option 3: do like GNU Gettext, except do
not require the primary language in $LANGUAGE to be consistent with LANG
/ LC_ALL.

Thus, we sanitize the environment even harder. What an absolute
disaster. Even if this was fixed tomorrow we would need to maintain this
hack until 2030.

Bug: https://bugs.gentoo.org/936670
(cherry picked from commit 5e6122b)
The x86 test files might not work on x86_64 Linux in certain cases,
for example if the kernel is configured without support for x86
executables (which also gets rid of the old system call interface).

Bug: https://bugs.gentoo.org/936911
(cherry picked from commit 9501228)
@rgommers
Copy link
Member Author

Updated to 1.5.2 and tested with the full NumPy CI (which looks good) in numpy/numpy#27550 (comment). Unit test failures here don't seem relevant after all.

@rgommers rgommers changed the title Merge in changes included in Meson 1.5.0rc1 Merge in changes included in Meson 1.5.2 Oct 14, 2024
@rgommers rgommers merged commit 3f28c54 into numpy:main-numpymeson Oct 14, 2024
6 of 30 checks passed
@rgommers rgommers deleted the merge-150rc1 branch October 14, 2024 13:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.