internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: mesonbuild/meson

Issue:
needs_exe_wrapper = false ignored in tests
In meson 0.50.x and earlier one could set the `needs_exe_wrapper` property of the cross file to false to tell meson that the cross binaries could be run natively, without a wrapper (such as when compiling x86 binaries on x86_64 platforms). In 0.51 this stopped working.

This is likely related to (and perhaps the corollary to #5818


Discussion:

Resolving patch:
diff --git a/mesonbuild/backend/backends.py b/mesonbuild/backend/backends.py
--- a/mesonbuild/backend/backends.py
+++ b/mesonbuild/backend/backends.py
@@ -83,7 +83,7 @@ def __init__(self, cmd_args, env=None, exe_wrapper=None,
 class TestSerialisation:
     def __init__(self, name: str, project: str, suite: str, fname: typing.List[str],
                  is_cross_built: bool, exe_wrapper: typing.Optional[build.Executable],
-                 is_parallel: bool, cmd_args: typing.List[str],
+                 needs_exe_wrapper: bool, is_parallel: bool, cmd_args: typing.List[str],
                  env: build.EnvironmentVariables, should_fail: bool,
                  timeout: typing.Optional[int], workdir: typing.Optional[str],
                  extra_paths: typing.List[str], protocol: str, priority: int):
@@ -104,6 +104,7 @@ def __init__(self, name: str, project: str, suite: str, fname: typing.List[str],
         self.extra_paths = extra_paths
         self.protocol = protocol
         self.priority = priority
+        self.needs_exe_wrapper = needs_exe_wrapper
 
 def get_backend_from_name(backend, build):
     if backend == 'ninja':
@@ -748,7 +749,8 @@ def create_test_serialisation(self, tests):
                 else:
                     raise MesonException('Bad object in test command.')
             ts = TestSerialisation(t.get_name(), t.project_name, t.suite, cmd, is_cross,
-                                   exe_wrapper, t.is_parallel, cmd_args, t.env,
+                                   exe_wrapper, self.environment.need_exe_wrapper(),
+                                   t.is_parallel, cmd_args, t.env,
                                    t.should_fail, t.timeout, t.workdir,
                                    extra_paths, t.protocol, t.priority)
             arr.append(ts)
diff --git a/mesonbuild/mtest.py b/mesonbuild/mtest.py
--- a/mesonbuild/mtest.py
+++ b/mesonbuild/mtest.py
@@ -460,7 +460,7 @@ def _get_cmd(self) -> typing.Optional[typing.List[str]]:
         elif not self.test.is_cross_built and run_with_mono(self.test.fname[0]):
             return ['mono'] + self.test.fname
         else:
-            if self.test.is_cross_built:
+            if self.test.is_cross_built and self.test.needs_exe_wrapper:
                 if self.test.exe_runner is None:
                     # Can not run test on cross compiled executable
                     # because there is no execute wrapper.


Test patch:
Repository: mesonbuild/meson

Issue:
pkg_config_path argument gives warnings if PKG_CONFIG_PATH environment contains duplicates
Somewhere between Meson 0.50.1 and 0.51.0, a spurious DEPRECATION warning began appearing if the `PKG_CONFIG_PATH` environment variable happens to have duplicate directories, which is safe:

```
The Meson build system
Version: 0.51.0
Source dir: /Meson/test cases/common/99 threads
Build dir: /Meson/test cases/common/99 threads/build
Build type: native build
DEPRECATION: Duplicated values in array option is deprecated. This will become a hard error in the future.
Project name: threads
Project version: undefined
C compiler for the build machine: cc (gcc 7.4.0 "cc (SUSE Linux) 7.4.0")
C++ compiler for the build machine: c++ (gcc 7.4.0 "c++ (SUSE Linux) 7.4.0")
C compiler for the host machine: cc (gcc 7.4.0 "cc (SUSE Linux) 7.4.0")
C++ compiler for the host machine: c++ (gcc 7.4.0 "c++ (SUSE Linux) 7.4.0")
Build machine cpu family: x86_64
Build machine cpu: x86_64
Run-time dependency threads found: YES 
Build targets in project: 2
Found ninja-1.8.2 at /usr/bin/ninja
[4/4] Linking target cppthreadprog.
```

See [this message](https://github.com/mesonbuild/meson/pull/5681#issuecomment-516050525) by @dcbaker.



Discussion:

Resolving patch:
diff --git a/mesonbuild/coredata.py b/mesonbuild/coredata.py
--- a/mesonbuild/coredata.py
+++ b/mesonbuild/coredata.py
@@ -718,7 +718,13 @@ def set_default_options(self, default_options, subproject, env):
         if env.first_invocation:
             p_env = os.environ.get('PKG_CONFIG_PATH')
             if p_env:
-                options['pkg_config_path'] = p_env.split(':')
+                # PKG_CONFIG_PATH may contain duplicates, which must be
+                # removed, else a duplicates-in-array-option warning arises.
+                pkg_config_paths = []
+                for k in p_env.split(':'):
+                    if k not in pkg_config_paths:
+                        pkg_config_paths.append(k)
+                options['pkg_config_path'] = pkg_config_paths
 
         for k, v in env.cmd_line_options.items():
             if subproject:
diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
--- a/mesonbuild/environment.py
+++ b/mesonbuild/environment.py
@@ -817,7 +817,7 @@ def _guess_nix_linker(compiler: typing.List[str], for_machine: MachineChoice,
                 v = 'unknown version'
             linker = AppleDynamicLinker(compiler, for_machine, i, prefix, version=v)
         elif 'GNU' in o:
-            if 'gold' in 'o':
+            if 'gold' in o:
                 i = 'GNU ld.gold'
             else:
                 i = 'GNU ld.bfd'


Test patch:
Repository: mesonbuild/meson

Issue:
benchmark() doesn't support same options as test()
benchmark() doesn't support same options as test(), 

In particular, it is lacking 'protocol' and 'depends'.


Discussion:
Does it actually not support them, or is this a problem with documentation. They actually share a codepath, with the only divergence I can see being at the very end when tests are benchmarks are grouped separately.
you get WARNING: Passed invalid keyword argument "depends". for ex

Resolving patch:
diff --git a/mesonbuild/interpreter.py b/mesonbuild/interpreter.py
--- a/mesonbuild/interpreter.py
+++ b/mesonbuild/interpreter.py
@@ -1948,13 +1948,15 @@ def get_cross_property_method(self, args, kwargs):
     {'target_type'}
 )
 
+_base_test_args = {'args', 'depends', 'env', 'should_fail', 'timeout', 'workdir', 'suite', 'priority', 'protocol'}
+
 permitted_kwargs = {'add_global_arguments': {'language', 'native'},
                     'add_global_link_arguments': {'language', 'native'},
                     'add_languages': {'required'},
                     'add_project_link_arguments': {'language', 'native'},
                     'add_project_arguments': {'language', 'native'},
                     'add_test_setup': {'exe_wrapper', 'gdb', 'timeout_multiplier', 'env', 'is_default'},
-                    'benchmark': {'args', 'env', 'should_fail', 'timeout', 'workdir', 'suite'},
+                    'benchmark': _base_test_args,
                     'build_target': known_build_target_kwargs,
                     'configure_file': {'input',
                                        'output',
@@ -2032,8 +2034,7 @@ def get_cross_property_method(self, args, kwargs):
                     'library': known_library_kwargs,
                     'subdir': {'if_found'},
                     'subproject': {'version', 'default_options', 'required'},
-                    'test': {'args', 'depends', 'env', 'is_parallel', 'should_fail', 'timeout', 'workdir',
-                             'suite', 'protocol', 'priority'},
+                    'test': set.union(_base_test_args, {'is_parallel'}),
                     'vcs_tag': {'input', 'output', 'fallback', 'command', 'replace_string'},
                     }
 
@@ -3364,8 +3365,13 @@ def func_generator(self, node, args, kwargs):
         self.generators.append(gen)
         return gen
 
+    @FeatureNewKwargs('benchmark', '0.46.0', ['depends'])
+    @FeatureNewKwargs('benchmark', '0.52.0', ['priority'])
     @permittedKwargs(permitted_kwargs['benchmark'])
     def func_benchmark(self, node, args, kwargs):
+        # is_parallel isn't valid here, so make sure it isn't passed
+        if 'is_parallel' in kwargs:
+            del kwargs['is_parallel']
         self.add_test(node, args, kwargs, False)
 
     @FeatureNewKwargs('test', '0.46.0', ['depends'])


Test patch:
Repository: mesonbuild/meson

Issue:
WARNING: Unknown CPU family 'sun4u'
While building glib2 on a Solaris 11.3 sun4u system (using pkgsrc) the following warning is issued:

WARNING: Unknown CPU family 'sun4u', please report this at https://github.com/mesonbuild/meson/issues/new with theoutput of `uname -a` and `cat /proc/cpuinfo`      

Output from 'uname -a': 
SunOS gcc-solaris11 5.11 11.3 sun4u sparc SUNW,SPARC-Enterprise

Output from /proc/cpuinfo is not possible since this is not available on a Solaris 11 system.

Output from the Solaris isainfo command:
sparcv9 sparc

Output from the Solaris isalist command:
sparcv9+fmuladd sparcv9+vis2 sparcv9+vis sparcv9 sparcv8plus+vis2 sparcv8plus+vis sparcv8plus sparcv8 sparcv8-fsmuld sparcv7 sparc



Discussion:
I'm assuming based on this information and [our table](https://mesonbuild.com/Reference-tables.html#cpu-families), this should map to `sparc64`, does that sound right?
Technically both 32-bit and 64-bit executables can run on sun4u, but I think modern use of sun4u is 64-bit, so mapping to sparc64 seems ok to me.

Resolving patch:
diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
--- a/mesonbuild/environment.py
+++ b/mesonbuild/environment.py
@@ -330,6 +330,8 @@ def detect_cpu_family(compilers: CompilersDict) -> str:
         trial = 'ppc'
     elif trial in ('amd64', 'x64', 'i86pc'):
         trial = 'x86_64'
+    elif trial in {'sun4u', 'sun4v'}:
+        trial = 'sparc64'
 
     # On Linux (and maybe others) there can be any mixture of 32/64 bit code in
     # the kernel, Python, system, 32-bit chroot on 64-bit host, etc. The only


Test patch:
Repository: mesonbuild/meson

Issue:
CMake subproject with MSVC generate many warnings D9025
I use the CMake subproject in a project with cl-compiler and the ninja build system. The meson automatically puts the **/ZI** argument, but when parsing a subproject, it puts the **/Zi** argument. This causes many warnings D9025.


Discussion:
I think this is part of a bigger issue: We should pass to cmake all external args (e.g. cflags), especially when cross compiling, because cmake could need them to run its checks, etc. But then all those flags will end into the generated `shared_library(c_args: ...)` and meson will duplicate them all.

I think the solution is to add a new feature to Meson, `shared_library(..., plain : true)` where meson won't add any other compiler arguments.
Adding flags for people to workaround issues is not scalable. Making it work automatically is.
@jpakkane doesn't have to be part of meson's public API, could be an internal feature just for the cmake module. When I said `shared_library(..., plain : true)` it's not the user writing that, but the AST generated by cmake module.
I don't think we need a specific feature for this. I would rather continue with the current argument [blacklist](https://github.com/mesonbuild/meson/blob/master/mesonbuild/cmake/interpreter.py#L84) approach and let meson handle those flags. Especially in this case where [debug information is controlled](https://docs.microsoft.com/en-us/cpp/build/reference/z7-zi-zi-debug-information-format?view=vs-2019). This is also how normal subprojects usually function unless the cargs are manually overwritten.
@SkyMaverick Could you please upload (Pastebin, etc.) `build/meson-logs/meson-log.txt` and `build/subprojects/<your subproject>/meson.build` if it exists? This would help me identify where I have to blacklist flags.
@mensinda Done. 
Used by libuv and libutf8proc as cmake-subprojects. [meson-log.txt](https://pastebin.com/iZ4LV6xN), [libutf8proc meson.build](https://pastebin.com/ArqANAgX), [libuv meson.build](https://pastebin.com/kQ7AzzRY). 
Also uploaded [build.ninja](https://pastebin.com/vdjixFLV) and [ninja stdout](https://pastebin.com/3CkDen8X), if need.

Resolving patch:
diff --git a/mesonbuild/cmake/interpreter.py b/mesonbuild/cmake/interpreter.py
--- a/mesonbuild/cmake/interpreter.py
+++ b/mesonbuild/cmake/interpreter.py
@@ -84,7 +84,8 @@
 blacklist_compiler_flags = [
     '/W1', '/W2', '/W3', '/W4', '/Wall',
     '/O1', '/O2', '/Ob', '/Od', '/Og', '/Oi', '/Os', '/Ot', '/Ox', '/Oy', '/Ob0',
-    '/RTC1', '/RTCc', '/RTCs', '/RTCu'
+    '/RTC1', '/RTCc', '/RTCs', '/RTCu',
+    '/Z7', '/Zi', '/ZI',
 ]
 
 blacklist_link_flags = [


Test patch:
Repository: mesonbuild/meson

Issue:
regression: nuisance warning for gfortran
@mensinda git bisect reveals
b1b8a7a7e356297741c3c8e5996928ff244578c8 is the first bad commit  that introduced spurious warning:

```
WARNING: No include directory found parsing "gfortran -xfortran -E -v -" output
```

This occurs with Linux and Windows (at least) with at least Gfortran 7 and 9.

This occurs for any trivial Fortran target.


Discussion:

Resolving patch:
diff --git a/mesonbuild/compilers/mixins/gnu.py b/mesonbuild/compilers/mixins/gnu.py
--- a/mesonbuild/compilers/mixins/gnu.py
+++ b/mesonbuild/compilers/mixins/gnu.py
@@ -85,8 +85,15 @@
 
 @functools.lru_cache(maxsize=None)
 def gnulike_default_include_dirs(compiler: typing.Tuple[str], lang: str) -> typing.List[str]:
-    if lang == 'cpp':
-        lang = 'c++'
+    lang_map = {
+        'c': 'c',
+        'cpp': 'c++',
+        'objc': 'objective-c',
+        'objcpp': 'objective-c++'
+    }
+    if lang not in lang_map:
+        return []
+    lang = lang_map[lang]
     env = os.environ.copy()
     env["LC_ALL"] = 'C'
     cmd = list(compiler) + ['-x{}'.format(lang), '-E', '-v', '-']


Test patch:
Repository: mesonbuild/meson

Issue:
32 bit warning with Xcode backend on Catalina
<img width="1512" alt="Screen Shot 2019-10-11 at 6 54 30 PM" src="https://user-images.githubusercontent.com/10180857/66689367-9144e780-ec58-11e9-83b3-9d9a523cd883.png">

Using a simple project with a single main.c

```c
#include <stdio.h>                                                                                                                                                                                                                     

int main(int argc, char **argv) {
  printf("Hello there.\n");
  return 0;
}
```

```python
project('c', 'c')

executable('main', 'main.c')
```

I ran `meson --backend xcode xcode` and then opened the Xcode project in Xcode and got the error in the screenshot.



Discussion:

Resolving patch:
diff --git a/mesonbuild/backend/xcodebackend.py b/mesonbuild/backend/xcodebackend.py
--- a/mesonbuild/backend/xcodebackend.py
+++ b/mesonbuild/backend/xcodebackend.py
@@ -634,7 +634,7 @@ def generate_xc_build_configuration(self):
             self.write_line('isa = XCBuildConfiguration;')
             self.write_line('buildSettings = {')
             self.indent_level += 1
-            self.write_line('ARCHS = "$(ARCHS_STANDARD_32_64_BIT)";')
+            self.write_line('ARCHS = "$(ARCHS_STANDARD_64_BIT)";')
             self.write_line('ONLY_ACTIVE_ARCH = YES;')
             self.write_line('SDKROOT = "macosx";')
             self.write_line('SYMROOT = "%s/build";' % self.environment.get_build_dir())


Test patch:
Repository: mesonbuild/meson

Issue:
run_command() with compiler object behind ccache fails.
So say you have a compiler object `cc`: 

```
cc = meson.get_compiler('c')
```

This compiler is a GCC behind ccache. `cc.get_id()` returns `gcc`, `cc.version()` returns the GCC version and other features seem to work well (`cc.compiles()` and whatnot).

But `run_command()` seems to be run on ccache directly! For instance, try to run: `run_command(cc, '-v')`

You won't get the output of `gcc -v` but the one of `ccache -v` (which is an invalid option, so `run_command(cc, '-v').returncode()` is 0, `stdout()` is empty and `stderr()` is ccache usage).

P.S.: `run_command()` [docs](https://mesonbuild.com/Reference-manual.html#run_command) says explicitly it should work on a compiler object:

> Runs the command specified in positional arguments. command can be a string, or the output of find_program(), files() or configure_file(), or a compiler object.


Discussion:

Resolving patch:
diff --git a/mesonbuild/interpreter.py b/mesonbuild/interpreter.py
--- a/mesonbuild/interpreter.py
+++ b/mesonbuild/interpreter.py
@@ -2382,6 +2382,7 @@ def run_command_impl(self, node, args, kwargs, in_builddir=False):
 
         m = 'must be a string, or the output of find_program(), files() '\
             'or configure_file(), or a compiler object; not {!r}'
+        expanded_args = []
         if isinstance(cmd, ExternalProgramHolder):
             cmd = cmd.held_object
             if isinstance(cmd, build.Executable):
@@ -2392,12 +2393,14 @@ def run_command_impl(self, node, args, kwargs, in_builddir=False):
             if not cmd.found():
                 raise InterpreterException('command {!r} not found or not executable'.format(cmd))
         elif isinstance(cmd, CompilerHolder):
-            cmd = cmd.compiler.get_exelist()[0]
+            exelist = cmd.compiler.get_exelist()
+            cmd = exelist[0]
             prog = ExternalProgram(cmd, silent=True)
             if not prog.found():
                 raise InterpreterException('Program {!r} not found '
                                            'or not executable'.format(cmd))
             cmd = prog
+            expanded_args = exelist[1:]
         else:
             if isinstance(cmd, mesonlib.File):
                 cmd = cmd.absolute_path(srcdir, builddir)
@@ -2417,7 +2420,6 @@ def run_command_impl(self, node, args, kwargs, in_builddir=False):
             if not os.path.isabs(cmd_path):
                 if cmd_path not in self.build_def_files:
                     self.build_def_files.append(cmd_path)
-        expanded_args = []
         for a in listify(cargs):
             if isinstance(a, str):
                 expanded_args.append(a)


Test patch:
Repository: mesonbuild/meson

Issue:
Coverage regression on macOS Catalina
On macOS Mojave, enabling `b_coverage=true` resulted in successfully instrumented test executables generating .gcno files. On Catalina, I instead get

```
ERROR: Linker APPLE ld doesn't implement coverage data generation.
```

The following patch seems to fix coverage generation on Catalina for me:

```diff
diff --git a/mesonbuild/linkers.py b/mesonbuild/linkers.py
index 84bfceb4..371220bf 100644
--- a/mesonbuild/linkers.py
+++ b/mesonbuild/linkers.py
@@ -580,6 +580,9 @@ class AppleDynamicLinker(PosixDynamicLinkerMixin, DynamicLinker):
             result.append(a)
         return result

+    def get_coverage_args(self) -> typing.List[str]:
+        return ['--coverage']
+
     def sanitizer_args(self, value: str) -> typing.List[str]:
         if value == 'none':
             return []
```

#6160 may be relevant here, as it suggests that clang coverage shouldn't be working at all with meson. I didn't investigate further to figure out why the above patch wasn't necessary on Mojave but now is.

If desired, I can open a PR with the above patch, but at this point I'm not confident I know what the root issue is.


Discussion:
FWIW, I opened issue #6191 a few minutes ago. Someone pointed out it was essentially a duplicate of this issue. I applied this fix to the meson master branch on my system and it does indeed correct the problem for me on macOS 10.15.1. It's not obvious this fix is correct in all situations since it might be incorrect for older macOS/Xcode versions. But that probably isn't true and it is unlikely anyone running an old macOS platform will upgrade Meson without also upgrading the platform.
Yes perhaps open a PR on this to run it through the CI which is still on Mojave last I looked.

Resolving patch:
diff --git a/mesonbuild/linkers.py b/mesonbuild/linkers.py
--- a/mesonbuild/linkers.py
+++ b/mesonbuild/linkers.py
@@ -580,6 +580,9 @@ def get_link_whole_for(self, args: typing.List[str]) -> typing.List[str]:
             result.append(a)
         return result
 
+    def get_coverage_args(self) -> typing.List[str]:
+        return ['--coverage']
+
     def sanitizer_args(self, value: str) -> typing.List[str]:
         if value == 'none':
             return []
@@ -633,6 +636,7 @@ def build_rpath_args(self, env: 'Environment', build_dir: str, from_dir: str,
         return args
 
 
+
 class GnuDynamicLinker(GnuLikeDynamicLinkerMixin, PosixDynamicLinkerMixin, DynamicLinker):
 
     """Representation of GNU ld.bfd and ld.gold."""


Test patch:
Repository: mesonbuild/meson

Issue:
Unknown CPU family 's390'
building with meson on an s390 (*not* s390x) yields a warning:
```
WARNING: Unknown CPU family 's390', please report this at https://github.com/mesonbuild/meson/issues/new with theoutput of `uname -a` and `cat /proc/cpuinfo`
```

s390 is 32-bit whereas s390x is 64-bit.  meson seems to work fine otherwise.

```sh
$ uname -a
Linux lgentoo3 4.14.12 #1 SMP Tue Jan 9 18:32:25 EST 2018 s390 8561 IBM GNU/Linux

$ cat /proc/cpuinfo
vendor_id       : IBM/S390
# processors    : 2
bogomips per cpu: 3241.00
max thread id   : 0
features        : esan3 zarch stfle msa ldisp eimm dfp edat etf3eh highgprs te vx vxd vxe gs sie 
facilities      : 0 1 2 3 4 6 7 8 9 10 12 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 30 31 32 33 34 35 36 37 38 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 57 58 59 60 61 73 74 75 76 77 80 81 82 128 129 130 131 133 134 135 146 147 148 150 151 152 155 156 168
cache0          : level=1 type=Data scope=Private size=128K line_size=256 associativity=8
cache1          : level=1 type=Instruction scope=Private size=128K line_size=256 associativity=8
cache2          : level=2 type=Data scope=Private size=4096K line_size=256 associativity=8
cache3          : level=2 type=Instruction scope=Private size=4096K line_size=256 associativity=8
cache4          : level=3 type=Unified scope=Shared size=262144K line_size=256 associativity=32
cache5          : level=4 type=Unified scope=Shared size=983040K line_size=256 associativity=60
processor 0: version = FF,  identification = 100003,  machine = 8561
processor 1: version = FF,  identification = 200003,  machine = 8561

cpu number      : 0
cpu MHz dynamic : 5200
cpu MHz static  : 5200

cpu number      : 1
cpu MHz dynamic : 5200
cpu MHz static  : 5200
```


Discussion:
I'm reading what the difference is between s390 and s390x, at it looks like historically in the Linux world s390 referred to the 31?-bit kernel and s390x referred to the 64-bit kernel, but that isn't hte case anymore? Did we make a mistake cannocializing s390x?
that is the case still.  i'm running a 32-bit userland here (the digression into 31-vs-32 prob doesn't matter to meson), not 64-bit.  meson knows only about 64-bit atm.

Resolving patch:
diff --git a/mesonbuild/envconfig.py b/mesonbuild/envconfig.py
--- a/mesonbuild/envconfig.py
+++ b/mesonbuild/envconfig.py
@@ -52,6 +52,7 @@
     'riscv64',
     'rl78',
     'rx',
+    's390',
     's390x',
     'sparc',
     'sparc64',
@@ -70,6 +71,7 @@
     'mips64',
     'ppc64',
     'riscv64',
+    's390x',
     'sparc64',
     'wasm64',
     'x86_64',


Test patch: