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

Issue:
Not passing --coverage for clang + meson coverage?
I get lots of weird errors like `error: undefined reference to 'llvm_gcda_start_file'` or `error: undefined reference to 'llvm_gcov_init'` when trying to build a coverage target with `CXX=clang++`, but as soon as I pass `LDFLAGS=--coverage`, those errors appear to be solved. GCC(g++) builds and produces coverage fine.

There is however another error probably caused by mismatch of gcov version -

```
build ci/travis ア ninja coverage-html 
[1/1] Generating HTML coverage report.
FAILED: /home/agauniyal/projects/termdb/build/meson-logs/coveragereport/index.html 
'lcov' '--directory' '/home/agauniyal/projects/termdb/build' '--capture' '--output-file' '/home/agauniyal/projects/termdb/build/meson-logs/coverage.info' '--no-checksum' && 'genhtml' '--prefix' '/home/agauniyal/projects/termdb/build' '--output-directory' '/home/agauniyal/projects/termdb/build/meson-logs/coveragereport' '--title' 'Code coverage' '--legend' '--show-details' '/home/agauniyal/projects/termdb/build/meson-logs/coverage.info'
Capturing coverage data from /home/agauniyal/projects/termdb/build
Found gcov version: 6.3.1
Scanning /home/agauniyal/projects/termdb/build for .gcda files ...
Out of memory!
Found 1 data files in /home/agauniyal/projects/termdb/build
Processing test.cpp.gcda
ninja: build stopped: subcommand failed.
```

but atleast the first error gets solved..


Discussion:

Resolving patch:
diff --git a/mesonbuild/compilers.py b/mesonbuild/compilers.py
--- a/mesonbuild/compilers.py
+++ b/mesonbuild/compilers.py
@@ -610,7 +610,7 @@ def get_coverage_args(self):
         return ['--coverage']
 
     def get_coverage_link_args(self):
-        return ['-lgcov']
+        return ['--coverage']
 
     def get_werror_args(self):
         return ['-Werror']


Test patch:
Repository: mesonbuild/meson

Issue:
want array.get() with fallback
I often find myself doing arrays of things like e.g. unit tests or exes or such which are then processed in a foreach loop. Sometimes each array element is an array in itself, so that 'extra' things like extra source files, extra deps and such can be added. This means that inside the array one has to have lots of 
```
extra_foo = []
if element.length() > N
  extra_foo = element.get(N)
endif
```

It would be nicer if we could just do:
```
extra_foo = element.get_with_fallback(N, [])
```
and ideally it would default to returning `[]` if no fallback is specified.


Discussion:
Or maybe we can tweak the existing `get()` somehow, like if it gets passed a second argument that would be the fallback.
Python does exactly that with `.get()`, so we could do it too.

Resolving patch:
diff --git a/mesonbuild/interpreterbase.py b/mesonbuild/interpreterbase.py
--- a/mesonbuild/interpreterbase.py
+++ b/mesonbuild/interpreterbase.py
@@ -501,12 +501,24 @@ def array_method_call(self, obj, method_name, args):
             return len(obj)
         elif method_name == 'get':
             index = args[0]
+            fallback = None
+            if len(args) == 2:
+                fallback = args[1]
+            elif len(args) > 2:
+                m = 'Array method \'get()\' only takes two arguments: the ' \
+                    'index and an optional fallback value if the index is ' \
+                    'out of range.'
+                raise InvalidArguments(m)
             if not isinstance(index, int):
                 raise InvalidArguments('Array index must be a number.')
             if index < -len(obj) or index >= len(obj):
-                raise InvalidArguments('Array index %s is out of bounds for array of size %d.' % (index, len(obj)))
+                if fallback is None:
+                    m = 'Array index {!r} is out of bounds for array of size {!r}.'
+                    raise InvalidArguments(m.format(index, len(obj)))
+                return fallback
             return obj[index]
-        raise InterpreterException('Arrays do not have a method called "%s".' % method_name)
+        m = 'Arrays do not have a method called {!r}.'
+        raise InterpreterException(m.format(method_name))
 
     def reduce_arguments(self, args):
         assert(isinstance(args, mparser.ArgumentNode))


Test patch:
diff --git a/test cases/common/67 foreach/meson.build b/test cases/common/67 foreach/meson.build
--- a/test cases/common/67 foreach/meson.build	
+++ b/test cases/common/67 foreach/meson.build	
@@ -1,8 +1,12 @@
 project('foreach', 'c')
 
 tests = [['test1', 'prog1', 'prog1.c'],
-  ['test2', 'prog2', 'prog2.c'],
-  ['test3', 'prog3', 'prog3.c']]
+  ['test2', 'prog2', 'prog2.c', 'fallback'],
+  ['test3', 'prog3', 'prog3.c', 'urgh']]
+
+assert(tests[0].get(3, 'fallbck') == 'fallbck', 'array #1 fallback did not match')
+assert(tests[1].get(3, 'failbk') == 'fallback', 'array #2 value did not match')
+assert(tests[2].get(3, 'urgh') == 'urgh', 'array #3 value did not match')
 
 foreach i : tests
   test(i.get(0), executable(i.get(1), i.get(2), install : true))
Repository: mesonbuild/meson

Issue:
jar install fails when strip enabled
My C library has a java binding. When I try to install library with `strip` option enabled, it fails because of the jar target. The following output belongs to the test case `java/1 basic`, with `install` argument added to the jar target:

```sh
$ DESTDIR=tmp ninja install
[0/1] Installing files.
Installing myprog.jar to tmp/usr/local/lib/x86_64-linux-gnu/myprog.jar
Stripping target 'myprog.jar'
Could not strip file.

Stdout:


Stderr:
strip:tmp/usr/local/lib/x86_64-linux-gnu/myprog.jar: File format not recognized


FAILED: install 
'/usr/bin/python3' '/usr/local/bin/meson' '--internal' 'install' '/home/fatih/git/meson/test cases/java/1 basic/build/meson-private/install.dat'
ninja: build stopped: subcommand failed.
```


Discussion:

Resolving patch:
diff --git a/mesonbuild/scripts/meson_install.py b/mesonbuild/scripts/meson_install.py
--- a/mesonbuild/scripts/meson_install.py
+++ b/mesonbuild/scripts/meson_install.py
@@ -237,6 +237,9 @@ def install_targets(d):
         elif os.path.isfile(fname):
             do_copyfile(fname, outname)
             if should_strip:
+                if fname.endswith('.jar'):
+                    print('Not stripping jar target:', os.path.split(fname)[1])
+                    continue
                 print('Stripping target {!r}'.format(fname))
                 ps, stdo, stde = Popen_safe(['strip', outname])
                 if ps.returncode != 0:


Test patch:
diff --git a/test cases/java/1 basic/installed_files.txt b/test cases/java/1 basic/installed_files.txt
new file mode 100644
--- /dev/null
+++ b/test cases/java/1 basic/installed_files.txt	
@@ -0,0 +1 @@
+usr/bin/myprog.jar
diff --git a/test cases/java/1 basic/meson.build b/test cases/java/1 basic/meson.build
--- a/test cases/java/1 basic/meson.build	
+++ b/test cases/java/1 basic/meson.build	
@@ -1,5 +1,7 @@
 project('simplejava', 'java')
 
 javaprog = jar('myprog', 'com/mesonbuild/Simple.java',
-  main_class : 'com.mesonbuild.Simple')
+  main_class : 'com.mesonbuild.Simple',
+  install : true,
+  install_dir : get_option('bindir'))
 test('mytest', javaprog)
Repository: mesonbuild/meson

Issue:
Compd should have command lines for all the compilers
I didn't see another bug that quite matched this request, so hopefully it's not a dup :)

What we need in Builder to improve our Vala support while running with the Meson build system is to get the compiler flags for `valac`. In particular, we're looking for those `--pkg gtk+-3.0 --pkg gio-2.0` type compiler flags.

We need these to prime `libvala` so that we can get relevant auto-completion results.


Discussion:
Ideally we should export those in the compdb automatically. If you go to a build dir with Vala code and do:

    ninja -t compdb vala_COMPILER

Does the output contain everything you need?
Most excellent, I think I can parse the flags out of that just fine!
Reopening, because the bug here is that we should generate that by default.

Resolving patch:
diff --git a/mesonbuild/backend/ninjabackend.py b/mesonbuild/backend/ninjabackend.py
--- a/mesonbuild/backend/ninjabackend.py
+++ b/mesonbuild/backend/ninjabackend.py
@@ -210,8 +210,9 @@ def generate(self, interp):
     # http://clang.llvm.org/docs/JSONCompilationDatabase.html
     def generate_compdb(self):
         ninja_exe = environment.detect_ninja()
-        ninja_compdb = [ninja_exe, '-t', 'compdb', 'c_COMPILER', 'cpp_COMPILER', 'c_CROSS_COMPILER',
-                        'cpp_CROSS_COMPILER']
+        native_compilers = ['%s_COMPILER' % i for i in self.build.compilers]
+        cross_compilers = ['%s_CROSS_COMPILER' % i for i in self.build.cross_compilers]
+        ninja_compdb = [ninja_exe, '-t', 'compdb'] + native_compilers + cross_compilers
         builddir = self.environment.get_build_dir()
         try:
             jsondb = subprocess.check_output(ninja_compdb, cwd=builddir)
diff --git a/run_unittests.py b/run_unittests.py
--- a/run_unittests.py
+++ b/run_unittests.py
@@ -951,6 +951,8 @@ def test_vala_c_warnings(self):
         for each in compdb:
             if each['file'].endswith('GLib.Thread.c'):
                 vala_command = each['command']
+            elif each['file'].endswith('GLib.Thread.vala'):
+                continue
             elif each['file'].endswith('retcode.c'):
                 c_command = each['command']
             else:


Test patch:
Repository: mesonbuild/meson

Issue:
gnome: gdbus_codegen includes outdir in include
So what I mean by that is if you have the tree:

- meson.build
- src
  - meson.build (calling `gnome.gdbus_codegen`)

The output source file will include `#include "src/foo.h"`

Our [test](https://github.com/mesonbuild/meson/blob/7144b03fd412e9a441d9abaa615d90af348a9137/test%20cases/frameworks/7%20gnome/gdbus/meson.build#L7) even relies upon this behavior which I'd argue is simply wrong.

The problem seems to be that `gdbus-codgen` gets the include line based upon the `--generate-c-code` flag. So either we need to run the command in the correct subdir or add a new flag to `gdbus-codgen` to specify the output directory.


Discussion:
The latter seems like the only workable solution. Having the generator put in random path segments to #includes seems just plain wrong.
Well it isn't random its what it was told, it just expects to be ran in the same directory as the output. Anyway I'll look into adding this upstream.
https://bugzilla.gnome.org/show_bug.cgi?id=778801

Resolving patch:
diff --git a/mesonbuild/modules/gnome.py b/mesonbuild/modules/gnome.py
--- a/mesonbuild/modules/gnome.py
+++ b/mesonbuild/modules/gnome.py
@@ -41,6 +41,7 @@
 
 native_glib_version = None
 girwarning_printed = False
+gdbuswarning_printed = False
 gresource_warning_printed = False
 _gir_has_extra_lib_arg = None
 
@@ -80,6 +81,15 @@ def __print_gresources_warning(self, state):
             gresource_warning_printed = True
         return []
 
+    @staticmethod
+    def _print_gdbus_warning():
+        global gdbuswarning_printed
+        if not gdbuswarning_printed:
+            mlog.warning('Code generated with gdbus_codegen() requires the root directory be added to\n'
+                         '  include_directories of targets with GLib < 2.51.3:',
+                         mlog.bold('https://github.com/mesonbuild/meson/issues/1387'))
+            gdbuswarning_printed = True
+
     def compile_resources(self, state, args, kwargs):
         self.__print_gresources_warning(state)
         glib_version = self._get_native_glib_version(state)
@@ -758,7 +768,13 @@ def gdbus_codegen(self, state, args, kwargs):
             cmd += ['--interface-prefix', kwargs.pop('interface_prefix')]
         if 'namespace' in kwargs:
             cmd += ['--c-namespace', kwargs.pop('namespace')]
-        cmd += ['--generate-c-code', '@OUTDIR@/' + namebase, '@INPUT@']
+
+        # https://git.gnome.org/browse/glib/commit/?id=ee09bb704fe9ccb24d92dd86696a0e6bb8f0dc1a
+        if mesonlib.version_compare(self._get_native_glib_version(state), '>= 2.51.3'):
+            cmd += ['--output-directory', '@OUTDIR@', '--generate-c-code', namebase, '@INPUT@']
+        else:
+            self._print_gdbus_warning()
+            cmd += ['--generate-c-code', '@OUTDIR@/' + namebase, '@INPUT@']
         outputs = [namebase + '.c', namebase + '.h']
         custom_kwargs = {'input': xml_file,
                          'output': outputs,


Test patch:
Repository: mesonbuild/meson

Issue:
Attribute error on logical operations
The following snippet:
```meson
if true and true or true
        message('Works')
endif
```

results in the following exception:
AttributeError: 'AndNode' object has no attribute 'subdir'


Discussion:
In case it helps, a quick workaround (obviously not a fix) is to start such expressions with 'false or', which is basically a nop.

That is, this raises the bogus exception:
`true and true or true`
but this doesn't:
`false or true and true or true`


Resolving patch:
diff --git a/mesonbuild/mparser.py b/mesonbuild/mparser.py
--- a/mesonbuild/mparser.py
+++ b/mesonbuild/mparser.py
@@ -193,9 +193,10 @@ def __init__(self, left, right):
         self.right = right
 
 class AndNode:
-    def __init__(self, lineno, colno, left, right):
-        self.lineno = lineno
-        self.colno = colno
+    def __init__(self, left, right):
+        self.subdir = left.subdir
+        self.lineno = left.lineno
+        self.colno = left.colno
         self.left = left
         self.right = right
 
@@ -436,7 +437,7 @@ def e2(self):
     def e3(self):
         left = self.e4()
         while self.accept('and'):
-            left = AndNode(left.lineno, left.colno, left, self.e4())
+            left = AndNode(left, self.e4())
         return left
 
     def e4(self):


Test patch:
diff --git a/test cases/common/40 logic ops/meson.build b/test cases/common/40 logic ops/meson.build
--- a/test cases/common/40 logic ops/meson.build	
+++ b/test cases/common/40 logic ops/meson.build	
@@ -87,3 +87,9 @@ if t and t and t and t and t and t and t and t and f
 else
   message('Ok.')
 endif
+
+if t and t or t
+  message('Ok.')
+else
+  error('Combination of and-or failed.')
+endif
Repository: mesonbuild/meson

Issue:
VS 2017 backend emits bad WindowsTargetPlatformVersion value
When I tried generating a VS 2017 solution, the generated app.vcxproj contained this:

```
<WindowsTargetPlatformVersion>10.0.14393.0\</WindowsTargetPlatformVersion>
```

Which then causes errors in other `.targets` files attempting to do a numeric comparison against that.
This value is probably taken straight from one of these environment variables:

```
WindowsSDKLibVersion=10.0.14393.0\
WindowsSDKVersion=10.0.14393.0\
```

The trailing backslash is a bit suspect, but may be there intentionally so it can be concatenated to 
```
WindowsSdkDir=C:\Program Files (x86)\Windows Kits\10\
```
directly.


Discussion:

Resolving patch:
diff --git a/mesonbuild/backend/vs2017backend.py b/mesonbuild/backend/vs2017backend.py
--- a/mesonbuild/backend/vs2017backend.py
+++ b/mesonbuild/backend/vs2017backend.py
@@ -24,4 +24,4 @@ def __init__(self, build):
         self.platform_toolset = 'v141'
         self.vs_version = '2017'
         # WindowsSDKVersion should be set by command prompt.
-        self.windows_target_platform_version = os.getenv('WindowsSDKVersion', None)
+        self.windows_target_platform_version = os.getenv('WindowsSDKVersion', None).rstrip('\\')


Test patch:
Repository: mesonbuild/meson

Issue:
Need dependency(..., headers_only : true) and so on for use with Valgrind
Similar to #726 but not the same.

Use case: I want to detect valgrind via pkg-config and pass the right includes for valgrind/valgrind.h to my build, but not link to the valgrind libs (which fails because they're static libs and not built with -fPIC, but is also unnecessary because everything we need is in the headers via magic macros).

I know of other use cases where this is needed, e.g. where glib headers are used for portable typedefs but no linking is done.

`cflags = run_command('pkg-config', '--cflags', 'dep').stdout().strip().split()` is not cross-compile friendly, so doesn't seem like a good solution.



Discussion:
I'm wondering if we actually need these getters, or if something like this wouldn't be better:
`valgrind_dep = dependency('valgrind', headers_only : true)`

I actually really like the idea of a `headers_only` kwarg here, and it's quite easy to implement too.


Resolving patch:
diff --git a/mesonbuild/dependencies.py b/mesonbuild/dependencies.py
--- a/mesonbuild/dependencies.py
+++ b/mesonbuild/dependencies.py
@@ -1483,6 +1483,14 @@ def get_link_args(self):
     def get_version(self):
         return self.version
 
+class ValgrindDependency(PkgConfigDependency):
+
+    def __init__(self, environment, kwargs):
+        PkgConfigDependency.__init__(self, 'valgrind', environment, kwargs)
+
+    def get_link_args(self):
+        return []
+
 def get_dep_identifier(name, kwargs):
     elements = [name]
     modlist = kwargs.get('modules', [])
@@ -1544,4 +1552,5 @@ def find_external_dependency(name, environment, kwargs):
             'gl': GLDependency,
             'threads': ThreadDependency,
             'python3': Python3Dependency,
+            'valgrind': ValgrindDependency,
             }


Test patch:
Repository: mesonbuild/meson

Issue:
RFE: please provide color output in the tests listing
With a long listing, it'd be nice to have the failing test name highlighted in red, and skipped test name highlighted in yellow, so it's easier to immediately see which tests were affected without looking at the result column. Also, this makes it easier to notice if anything failed.


Discussion:
We already have functions for doing this in `mlog`, so it should be fairly trivial to implement this.

Resolving patch:
diff --git a/mesontest.py b/mesontest.py
--- a/mesontest.py
+++ b/mesontest.py
@@ -22,6 +22,7 @@
 from mesonbuild import build
 from mesonbuild import environment
 from mesonbuild.dependencies import ExternalProgram
+from mesonbuild import mlog
 
 import time, datetime, multiprocessing, json
 import concurrent.futures as conc
@@ -283,7 +284,16 @@ def print_stats(self, numlen, tests, name, result, i, logfile, jsonlogfile):
         result_str = '%s %s  %s%s%s%5.2f s' % \
             (num, name, padding1, result.res, padding2, result.duration)
         if not self.options.quiet or result.res != 'OK':
-            print(result_str)
+            if result.res != 'OK' and mlog.colorize_console:
+                if result.res == 'FAIL' or result.res == 'TIMEOUT':
+                    decorator = mlog.red
+                elif result.res == 'SKIP':
+                    decorator = mlog.yellow
+                else:
+                    sys.exit('Unreachable code was ... well ... reached.')
+                print(decorator(result_str).get_text(True))
+            else:
+                print(result_str)
         result_str += "\n\n" + result.get_log()
         if (result.returncode != GNU_SKIP_RETURNCODE) \
                 and (result.returncode != 0) != result.should_fail:


Test patch:
Repository: mesonbuild/meson

Issue:
Ninja include prefix wrong with italian version of Msvc 2015
Meson looks for the prefix to match the /showincludes directive for ninja using two colon ('Note: including file: d:\MyDir\include\stdio.h') but the italian version of the visual studio compiler puts only one and writes 'Nota: file incluso  d:\MyDir\include\stdio.h' so meson matches the second colon after the drive, using as a prefix 'Nota: file incluso  d:' (or similar, depends form where you installed things).

The net result is that the include dependecies are not working correctly but only for a a limited number of file.

For the italian part the fix is trivial, in ninjabackend.c, in detect_vs_dep_prefix(...):

```python
            if line.endswith('stdio.h'):
                # Match for italian version, with only one ':'
                if line.startswith('Nota: file incluso'):
                    matchstr = 'Nota: file incluso'
                else:
                    matchstr = ':'.join(line.split(':')[0:2]) + ':'
                with open(tempfilename, 'a') as binfile:

```

but maybe other languages have the same problem.




Discussion:
What happens if you call `chcp 850` before calling meson?

[Changing MsBuild error message language](http://stackoverflow.com/questions/2286216/changing-msbuild-error-message-language)
Nothing change (the consolle was already with codepage 850), I tried half day yesterday to change in a fast way the language for cl.exe but the only solution was to uninstall visual studio and install the english version, without the language pack.

Resolving patch:
diff --git a/mesonbuild/backend/ninjabackend.py b/mesonbuild/backend/ninjabackend.py
--- a/mesonbuild/backend/ninjabackend.py
+++ b/mesonbuild/backend/ninjabackend.py
@@ -175,11 +175,16 @@ def detect_vs_dep_prefix(self, tempfilename):
                               stdout=subprocess.PIPE, stderr=subprocess.PIPE)
         (stdo, _) = pc.communicate()
 
+        # We want to match 'Note: including file: ' in the line
+        # 'Note: including file: d:\MyDir\include\stdio.h', however
+        # different locales have different messages with a different
+        # number of colons. Match up to the the drive name 'd:\'.
+        matchre = re.compile(rb"^(.*\s)[a-zA-Z]:\\.*stdio.h$")
         for line in stdo.split(b'\r\n'):
-            if line.endswith(b'stdio.h'):
-                matchstr = b':'.join(line.split(b':')[0:2]) + b':'
+            match = matchre.match(line)
+            if match:
                 with open(tempfilename, 'ab') as binfile:
-                    binfile.write(b'msvc_deps_prefix = ' + matchstr + b'\n')
+                    binfile.write(b'msvc_deps_prefix = ' + match.group(1) + b'\n')
                 return open(tempfilename, 'a')
         raise MesonException('Could not determine vs dep dependency prefix string.')
 


Test patch:
Repository: mesonbuild/meson

Issue:
Meson mistakenly reports executable keyword name_suffix as unknown
When using the following code:
`executable('hello-world', 'main.c', name_suffix:'js')`
Meson reports:
`WARNING: Unknown keyword argument(s) in target hello-world: name_suffix.`


Discussion:
This appears to be a documentation issue, as it looks like it accepts `suffix`.
But name_suffix also changes behaviour.
Same problem with suffix:
`WARNING: Unknown keyword argument(s) in target hello-world: suffix.`

Resolving patch:
diff --git a/mesonbuild/build.py b/mesonbuild/build.py
--- a/mesonbuild/build.py
+++ b/mesonbuild/build.py
@@ -42,6 +42,7 @@
                       'dependencies': True,
                       'install_dir': True,
                       'main_class': True,
+                      'name_suffix': True,
                       'gui_app': True,
                       'extra_files': True,
                       'install_rpath': True,
@@ -62,7 +63,6 @@
 known_lib_kwargs.update({'version': True, # Only for shared libs
                          'soversion': True, # Only for shared libs
                          'name_prefix': True,
-                         'name_suffix': True,
                          'vs_module_defs': True, # Only for shared libs
                          'vala_header': True,
                          'vala_vapi': True,


Test patch: