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

Issue:
meson-0.49.0 Windows installation misses most of the /scripts
```Meson\lib\mesonbuild\scripts``` contains only two files:
```
depfixer.pyc
__init__.pyc
```
Every other script is missing. This happens both on x86 and x64 installations.


Discussion:

Resolving patch:
diff --git a/msi/createmsi.py b/msi/createmsi.py
--- a/msi/createmsi.py
+++ b/msi/createmsi.py
@@ -78,13 +78,19 @@ def __init__(self):
         for sd in self.staging_dirs:
             self.feature_components[sd] = []
 
+    def get_all_modules_from_dir(self, dirname):
+        modname = os.path.basename(dirname)
+        modules = [os.path.splitext(os.path.split(x)[1])[0] for x in glob(os.path.join(dirname, '*'))]
+        modules = ['mesonbuild.' + modname + '.' + x for x in modules if not x.startswith('_')]
+        return modules
+
     def build_dist(self):
         for sdir in self.staging_dirs:
             if os.path.exists(sdir):
                 shutil.rmtree(sdir)
         main_stage, ninja_stage = self.staging_dirs
-        modules = [os.path.splitext(os.path.split(x)[1])[0] for x in glob(os.path.join('mesonbuild/modules/*'))]
-        modules = ['mesonbuild.modules.' + x for x in modules if not x.startswith('_')]
+        modules = self.get_all_modules_from_dir('mesonbuild/modules')
+        modules += self.get_all_modules_from_dir('mesonbuild/scripts')
         modules += ['distutils.version']
         modulestr = ','.join(modules)
         python = shutil.which('python')


Test patch:
Repository: mesonbuild/meson

Issue:
run_target improperly handles command if 'python' is in meson's installation path
My build environment is RHEL 7.6 with the python 3.6 Red Hat software collection enabled in my .bashrc.  Meson was installed by running ``pip3.6 install .`` as root in the ``meson-0.49.0/`` folder from a fresh download.  (This issue also happens in meson 48.)

I was setting up a custom run_target to run cppcheck with the command
```
run_target('cppcheck', command : ['cppcheck', '--project=' + join_paths(meson.build_root(), 'compile_commands.json')])
```
but noticed that it was failing to run with the following error message:
```
Could not execute command "--project=[build dir]/compile_commands.json". File not found.
FAILED: meson-cppcheck
/opt/rh/rh-python36/root/usr/bin/meson --internal commandrunner [src dir] [build dir] '' /opt/rh/rh-python36/root/usr/bin/meson cppcheck --project=[build dir]/compile_commands.json
ninja: build stopped: subcommand failed
```

I traced the issue for a bit and it the issue appears to be in ``commandrunner.py`` line 61 (ironically the line with the comment "Hack." haha): it looks for the presence of the string ``python`` in the meson path, presumably to catch instances of meson being launched with a ``python3 meson`` call.  However it ignores the possibility that python is simply a part of the path to the meson executable.  When this happens, the commandrunner script grabs the fifth argument and assumes that it's part of the meson command, which is wrong.

I'm currently working around the issue by inserting an empty argument into the run_target command, like this:
```
run_target('cppcheck', command : ['', 'cppcheck', '--project=' + join_paths(meson.build_root(), 'compile_commands.json')])
```


Discussion:

Resolving patch:
diff --git a/mesonbuild/scripts/commandrunner.py b/mesonbuild/scripts/commandrunner.py
--- a/mesonbuild/scripts/commandrunner.py
+++ b/mesonbuild/scripts/commandrunner.py
@@ -16,6 +16,7 @@
 what to run, sets up the environment and executes the command."""
 
 import sys, os, subprocess, shutil, shlex
+import re
 
 def run_command(source_dir, build_dir, subdir, meson_command, command, arguments):
     env = {'MESON_SOURCE_ROOT': source_dir,
@@ -49,6 +50,9 @@ def run_command(source_dir, build_dir, subdir, meson_command, command, arguments
         print('Could not execute command "{}": {}'.format(command, err))
         sys.exit(1)
 
+def is_python_command(cmdname):
+    end_py_regex = r'python(3|3\.\d+)?(\.exe)?$'
+    return re.search(end_py_regex, cmdname) is not None
 
 def run(args):
     if len(args) < 4:
@@ -58,7 +62,7 @@ def run(args):
     build_dir = args[1]
     subdir = args[2]
     meson_command = args[3]
-    if 'python' in meson_command: # Hack.
+    if is_python_command(meson_command):
         meson_command = [meson_command, args[4]]
         command = args[5]
         arguments = args[6:]


Test patch:
Repository: mesonbuild/meson

Issue:
0.49.0 fails to find Qt5 using qmake
My CI fails on both macOS and Windows:
https://travis-ci.org/z3ntu/razer_test/jobs/468630035
https://ci.appveyor.com/project/z3ntu/razer-test/builds/21043013/job/5upak41rvyneo2qu

`meson.build:20:0: ERROR:  Dependency "qt5" not found, tried pkgconfig, qmake-qt5 and qmake`

On those platforms, meson used the `qmake` detection with earlier versions


Discussion:
The culprit is aa04147a4a2a37aee197ebc0ed179c6fb582b3e9. CC @dcbaker
![image](https://user-images.githubusercontent.com/3768500/50053954-f5804300-013c-11e9-8686-32c8426ff5c3.png)

It also seems that using pkg-config is just plain broken (and has been for some time), at least the brew install.

Resolving patch:
diff --git a/mesonbuild/dependencies/ui.py b/mesonbuild/dependencies/ui.py
--- a/mesonbuild/dependencies/ui.py
+++ b/mesonbuild/dependencies/ui.py
@@ -14,7 +14,6 @@
 
 # This file contains the detection logic for external dependencies that
 # are UI-related.
-
 import functools
 import os
 import re
@@ -288,7 +287,15 @@ def _pkgconfig_detect(self, mods, kwargs):
             self.compile_args += m.get_compile_args()
             if self.private_headers:
                 qt_inc_dir = m.get_pkgconfig_variable('includedir', dict())
-                mod_private_inc = _qt_get_private_includes(os.path.join(qt_inc_dir, 'Qt' + m_name), m_name, m.version)
+                mod_private_dir = os.path.join(qt_inc_dir, 'Qt' + m_name)
+                if not os.path.isdir(mod_private_dir):
+                    # At least some versions of homebrew don't seem to set this
+                    # up correctly. /usr/local/opt/qt/include/Qt + m_name is a
+                    # symlink to /usr/local/opt/qt/include, but the pkg-config
+                    # file points to /usr/local/Cellar/qt/x.y.z/Headers/, and
+                    # the Qt + m_name there is not a symlink, it's a file
+                    mod_private_dir = qt_inc_dir
+                mod_private_inc = _qt_get_private_includes(mod_private_dir, m_name, m.version)
                 for dir in mod_private_inc:
                     self.compile_args.append('-I' + dir)
             self.link_args += m.get_link_args()
@@ -334,10 +341,9 @@ def _find_qmake(self, qmake):
                 return ExternalProgram.from_bin_list(self.env.cross_info.config['binaries'], 'qmake')
         elif self.env.config_info:
             # Prefer suffixed to unsuffixed version
-            p = ExternalProgram.from_bin_list(self.env.config_info.binaries, 'qmake-' + self.name)
+            p = ExternalProgram.from_bin_list(self.env.config_info.binaries, 'qmake')
             if p.found():
                 return p
-            return ExternalProgram.from_bin_list(self.env.config_info.binaries, 'qmake')
         return ExternalProgram(qmake, silent=True)
 
     def _qmake_detect(self, mods, kwargs):


Test patch:
Repository: mesonbuild/meson

Issue:
Qt5 module complains when the (previously) optional lrelease program isn't found
New behavior in 0.49.0:
`meson.build:47:0: ERROR:  Program(s) ['lrelease'] not found or not executable`
On quite many distributions the `lrelease` tool is only in the `qt5-tools` (or similarly named) package while the base parts of Qt are in `qt5-base` (which was previously enough to use Qt5 with meson).


Discussion:

Resolving patch:
diff --git a/mesonbuild/dependencies/ui.py b/mesonbuild/dependencies/ui.py
--- a/mesonbuild/dependencies/ui.py
+++ b/mesonbuild/dependencies/ui.py
@@ -243,7 +243,7 @@ def gen_bins():
                 if self.bindir:
                     yield os.path.join(self.bindir, b), b, False
                 yield '{}-{}'.format(b, self.name), b, False
-                yield b, b, self.required
+                yield b, b, self.required if b != 'lrelease' else False
 
         for b, name, required in gen_bins():
             if found[name].found():


Test patch:
Repository: mesonbuild/meson

Issue:
clang 6.x warning when using precompiled header input with .h extension
If my precompiled header ends with ".h", clang assumes the input type is `c-header`, but since Clang is being invoked as `clang++` it knows it needs to treat it as a `c++-header`, but it complains about it:
```
clang-6.0: warning: treating 'c-header' input as 'c++-header' when in C++ mode, this behavior is deprecated [-Wdeprecated]
```
It looks like meson needs to be adding `-x c++-header` to the compile command for the precompiled header, since it already does know the what language the precompiled header is for anyway.


Discussion:

Resolving patch:
diff --git a/mesonbuild/backend/ninjabackend.py b/mesonbuild/backend/ninjabackend.py
--- a/mesonbuild/backend/ninjabackend.py
+++ b/mesonbuild/backend/ninjabackend.py
@@ -2184,6 +2184,10 @@ def generate_msvc_pch_command(self, target, compiler, pch):
 
     def generate_gcc_pch_command(self, target, compiler, pch):
         commands = self._generate_single_compile(target, compiler)
+        if pch.split('.')[-1] == 'h' and compiler.language == 'cpp':
+            # Explicitly compile pch headers as C++. If Clang is invoked in C++ mode, it actually warns if
+            # this option is not set, and for gcc it also makes sense to use it.
+            commands += ['-x', 'c++-header']
         dst = os.path.join(self.get_target_private_dir(target),
                            os.path.basename(pch) + '.' + compiler.get_pch_suffix())
         dep = dst + '.' + compiler.get_depfile_suffix()


Test patch:
Repository: mesonbuild/meson

Issue:
Unknown CPU family 'parisc64'
The HP PA-RISC processors can do 64 bit for ages. However many of the "smaller" (e.g. my C3600) machines are usually operated with a 32 bit kernel if they have less than 4GB RAM:

```
Linux voyager 4.16.0 #1 Tue Apr 3 23:20:04 CEST 2018 parisc PA8600 (PCX-W+) 9000/785/C3600 GNU/Linux
```

Machines with more RAM or certain types of machines require a 64 bit kernel:

```
Linux pioneer 4.19.9 #2 SMP Fri Dec 14 18:57:12 CET 2018 parisc64 PA8800 (Mako) 9000/785/C8000 GNU/Linux
```

The twist is: there is no 64 bit userspace on these machines, so regardless of what the kernel says, the userspace is always 32 bit.

cpuinfo of my C8000 (only first processor):
```
processor       : 0
cpu family      : PA-RISC 2.0
cpu             : PA8800 (Mako)
cpu MHz         : 1000.000000
physical id     : 0
siblings        : 2
core id         : 0
capabilities    : os64 iopdir_fdc needs_equivalent_aliasing (0x35)
model           : 9000/785/C8000
model name      : Crestone Peak Fast?
hversion        : 0x000088b0
sversion        : 0x00000491
I-cache         : 32768 KB
D-cache         : 32768 KB (WB, direct mapped)
ITLB entries    : 240
DTLB entries    : 240 - shared with ITLB
bogomips        : 1988.60
software id     : 6266852346624179925
```

For reference, this is my single-core C3600 running a 32 bit kernel:
```
processor       : 0
cpu family      : PA-RISC 2.0
cpu             : PA8600 (PCX-W+)
cpu MHz         : 552.000000
capabilities    : os32 os64 nva_supported (0x03)
model           : 9000/785/C3600
model name      : Allegro W+
hversion        : 0x00005cf0
sversion        : 0x00000481
I-cache         : 512 KB
D-cache         : 1024 KB (WB, direct mapped)
ITLB entries    : 160
DTLB entries    : 160 - shared with ITLB
bogomips        : 1099.77
software id     : 2001234816
```


Discussion:
Given that, is there ever a case where `parisc64` would make sense? Can we just always return `parisc` regardless of whether the kernel is 64 or 32 bit?
Maybe eventually when someone finally does a 64 bit userspace, but not at the moment.

Resolving patch:
diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
--- a/mesonbuild/environment.py
+++ b/mesonbuild/environment.py
@@ -246,6 +246,10 @@ def detect_cpu_family(compilers):
             trial = 'arm'
     # Add more quirks here as bugs are reported. Keep in sync with detect_cpu()
     # below.
+    elif trial == 'parisc64':
+        # ATM there is no 64 bit userland for PA-RISC. Thus always
+        # report it as 32 bit for simplicity.
+        trial = 'parisc'
 
     if trial not in known_cpu_families:
         mlog.warning('Unknown CPU family {!r}, please report this at '


Test patch:
Repository: mesonbuild/meson

Issue:
failing test_introspect_json_dump on new OS (=Solaris)
I get a rare issue concerning the test_introspect_json_dump:

>
>======================================================================
FAIL: test_introspect_json_dump (__main__.AllPlatformTests)
>----------------------------------------------------------------------
>Traceback (most recent call last):
>  File "./run_unittests.py", line 3319, in test_introspect_json_dump
>    self.assertPathListEqual(res['buildsystem_files'], bs_files)
>  File "./run_unittests.py", line 1256, in assertPathListEqual
>    self.assertPathEqual(i[0], i[1])
>  File "./run_unittests.py", line 1247, in assertPathEqual
>    self.assertEqual(PurePath(path1), PurePath(path2))
>AssertionError: PureP[37 chars]on.git/test cases/unit/52 introspection/staticlib/meson.build') != PureP[37 chars]on.git/test cases/unit/52 introspection/sharedlib/meson.build')
>
>

Looking into the respective lines of code show that in the assertPathListEqual test there is an element change. All three elements are there and the same, but the parts with "sharedlib" and "staticlib" are vice versa. Meaning ('pseudo code for simplicity'):
> bs_files = ['meson.build', 'sharedlib/meson.build', 'staticlib/meson.build']
> buildysystem_files = ['meson.build', 'staticlib/meson.build', 'sharedlib/meson.build']

The content in buildsystem_files is as it is extracted by the test, inside the respective meson-info-file the order of the paths is "['meson.build', 'staticlib/meson.build', 'sharedlib/meson.build']". So the paths seems to be scrambled on their way into that file.

As I do not know what the test shall to since it did not pass yet (is the order needed or not) I would appreciate to get some help on this. When this is done I am a way further on running meson on Solaris.


Discussion:

Resolving patch:
diff --git a/run_unittests.py b/run_unittests.py
--- a/run_unittests.py
+++ b/run_unittests.py
@@ -3340,7 +3340,7 @@ def assertKeyTypes(key_type_list, obj):
         # Check buildsystem_files
         bs_files = ['meson.build', 'sharedlib/meson.build', 'staticlib/meson.build']
         bs_files = [os.path.join(testdir, x) for x in bs_files]
-        self.assertPathListEqual(res['buildsystem_files'], bs_files)
+        self.assertPathListEqual(list(sorted(res['buildsystem_files'])), list(sorted(bs_files)))
 
         # Check dependencies
         dependencies_to_find = ['threads']


Test patch:
Repository: mesonbuild/meson

Issue:
Linkage errors due to malformed ninja script
Using meson to build my project generates a ninja file that fails to link at the final stage. Downgrading to version `0.47.2-1` fixes the problem.

Upon further investigation it seems the culprit is this line in my ninja file:

`LINK_ARGS = -L=-L-L/usr/lib// -L=-L-lgtkd-3 -L=-L-ldl`

It looked odd that the arguments had the `-L` argument duplicated. And in fact, removing the extra argument allowed ninja to successfully link my project:

`LINK_ARGS = -L=-L/usr/lib// -L=-lgtkd-3 -L=-ldl`

@FFY00 


Discussion:
@GoaLitiuM and @ximion I don't have the time to search for the patch that broke this right now, maybe you could look into this. I can still answer questions, I just can't do extensive research/testing since I still have a few exams left.

Resolving patch:
diff --git a/mesonbuild/compilers/d.py b/mesonbuild/compilers/d.py
--- a/mesonbuild/compilers/d.py
+++ b/mesonbuild/compilers/d.py
@@ -380,7 +380,7 @@ def translate_args_to_nongnu(cls, args):
                 # translate library link flag
                 dcargs.append('-L=' + arg)
                 continue
-            elif arg.startswith('-L'):
+            elif arg.startswith('-L/') or arg.startswith('-L./'):
                 # we need to handle cases where -L is set by e.g. a pkg-config
                 # setting to select a linker search path. We can however not
                 # unconditionally prefix '-L' with '-L' because the user might


Test patch:
Repository: mesonbuild/meson

Issue:
Meson not detecting dub packages with different compilers and arch
Meson isn't accepting my DUB compiled libs, even though they were compiled using same tool.

`> dub build daemonize   `
```
Building package daemonize in /home/ricardo/.dub/packages/daemonize-0.2.1/daemonize/
Performing "debug" build using /usr/bin/dmd for x86_64.
daemonize 0.2.1: building configuration "default"... 
```

`> meson build`
```
...
Found pkg-config: /usr/bin/pkg-config (1.6.0)
Dependency gtkd-3 found: YES 3.8.5
Found DUB: /usr/bin/dub (DUB version 1.13.0, built on Jan 05 2019)
ERROR: daemonize found but it wasn't compiled with dmd
Dependency daemonize found: NO

meson.build:20:0: ERROR: Dependency "daemonize" not found
```

Even though both commands report DMD being used as compiler, Meson still believes the library wasn't compiled with DMD.

Tested with DMD and LDC.


Discussion:

Resolving patch:
diff --git a/mesonbuild/dependencies/base.py b/mesonbuild/dependencies/base.py
--- a/mesonbuild/dependencies/base.py
+++ b/mesonbuild/dependencies/base.py
@@ -1674,9 +1674,9 @@ def _find_right_lib_path(self, default_path, comp, description, folder_only=Fals
             return ''
 
         # Ex.: library-debug-linux.posix-x86_64-ldc_2081-EF934983A3319F8F8FF2F0E107A363BA
-        build_name = 'library-{}-{}-{}-{}_{}'.format(description['buildType'], '.'.join(description['platform']), '.'.join(description['architecture']), comp, d_ver)
+        build_name = '-{}-{}-{}-{}_{}'.format(description['buildType'], '.'.join(description['platform']), '.'.join(description['architecture']), comp, d_ver)
         for entry in os.listdir(module_build_path):
-            if entry.startswith(build_name):
+            if build_name in entry:
                 for file in os.listdir(os.path.join(module_build_path, entry)):
                     if file == lib_file_name:
                         if folder_only:


Test patch:
Repository: mesonbuild/meson

Issue:
Modifications to PCH don't trigger rebuild of the target with GCC
Modifying the header file only rebuilds the PCH, but doesn't rebuild the target. If a header that is included by the PCH is modified, then only the sources that also `#include` it will be rebuilt, which leads to inconsistencies and surprising bugs.

I've only tested this with GCC 8.2.1 and Clang 7.0.1 so far, C only. With clang it works fine: updating the pch rebuilds the whole project. I'm not sure if this might be a GCC bug (omitting command-line includes from the depfile?), but even if it is, I think it's worth working around in Meson anyway.


Discussion:

Resolving patch:
diff --git a/mesonbuild/backend/ninjabackend.py b/mesonbuild/backend/ninjabackend.py
--- a/mesonbuild/backend/ninjabackend.py
+++ b/mesonbuild/backend/ninjabackend.py
@@ -2220,14 +2220,7 @@ def generate_single_compile(self, target, outfile, src, is_generated=False, head
             elif not self.has_dir_part(d):
                 d = os.path.join(self.get_target_private_dir(target), d)
             element.add_orderdep(d)
-        if compiler.id == 'msvc':
-            # MSVC does not show includes coming from the PCH with '/showIncludes',
-            # thus we must add an implicit dependency to the generated PCH.
-            element.add_dep(pch_dep)
-        else:
-            # All other compilers properly handle includes through the PCH, so only an
-            # orderdep is needed to make the initial build without depfile work.
-            element.add_orderdep(pch_dep)
+        element.add_dep(pch_dep)
         # Convert from GCC-style link argument naming to the naming used by the
         # current compiler.
         commands = commands.to_native()


Test patch:
Repository: mesonbuild/meson

Issue:
Cuda Tests fail when werror=true
When building a project containing cuda code, if the default_options are set to have werror=true, the build fails with
```sh
  File "/usr/local/lib/python3.6/dist-packages/meson-0.49.999-py3.6.egg/mesonbuild/backend/backends.py", line 569, in generate_basic_compiler_args
    commands += compiler.get_werror_args()
AttributeError: 'CudaCompiler' object has no attribute 'get_werror_args'
```
This can be seen in the tests, particularly `test cases/cuda/1 simple`

I am running off `627d0d1f3e`. Thank you.


Discussion:

Resolving patch:
diff --git a/mesonbuild/compilers/cuda.py b/mesonbuild/compilers/cuda.py
--- a/mesonbuild/compilers/cuda.py
+++ b/mesonbuild/compilers/cuda.py
@@ -157,6 +157,9 @@ def get_optimization_args(self, optimization_level):
     def get_debug_args(self, is_debug):
         return cuda_debug_args[is_debug]
 
+    def get_werror_args(self):
+        return ['-Werror']
+
     def get_linker_exelist(self):
         return self.exelist[:]
 


Test patch:
Repository: mesonbuild/meson

Issue:
Scripts ran with `meson runpython` don't have their directory in sys.path
Normally, when Python executes a script, it sets up `sys.path` so that the script's parent directory is the first element. This lets scripts do local imports. Meson's wrapper, however, doesn't respect that, so anything that expects to import custom modules breaks.

[Here](https://github.com/taisei-project/taisei/tree/master/scripts) is an example from Taisei Project with a bunch of scripts that import utility functions from a common library. It works fine on *nix systems (and mingw), but fails on windows where the runpython wrapper is used.


Discussion:

Resolving patch:
diff --git a/mesonbuild/mesonmain.py b/mesonbuild/mesonmain.py
--- a/mesonbuild/mesonmain.py
+++ b/mesonbuild/mesonmain.py
@@ -80,6 +80,7 @@ def add_runpython_arguments(self, parser):
     def run_runpython_command(self, options):
         import runpy
         sys.argv[1:] = options.script_args
+        sys.path.insert(0, os.path.dirname(options.script_file))
         runpy.run_path(options.script_file, run_name='__main__')
         return 0
 


Test patch:
Repository: mesonbuild/meson

Issue:
Dependency found but it isn't a library
For libraries declared with `staticLibrary`, `sourceLibrary` or `dynamicLibrary` in a `dub` package, meson will return this:
```
...
Dependency gtkd-3 found: YES 3.8.5
Found DUB: /usr/bin/dub (DUB version 1.13.0, built on Jan 05 2019)
ERROR: riverd-lua found but it isn't a library
Dependency riverd-lua found: NO

meson.build:19:0: ERROR: Dependency "riverd-lua" not found
```


Discussion:

Resolving patch:
diff --git a/mesonbuild/dependencies/base.py b/mesonbuild/dependencies/base.py
--- a/mesonbuild/dependencies/base.py
+++ b/mesonbuild/dependencies/base.py
@@ -1776,7 +1776,7 @@ def __init__(self, name, environment, kwargs):
 
                 not_lib = True
                 if 'targetType' in package:
-                    if package['targetType'] == 'library':
+                    if package['targetType'] in ['library', 'sourceLibrary', 'staticLibrary', 'dynamicLibrary']:
                         not_lib = False
 
                 if not_lib:


Test patch: