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

Issue:
VS 2017 backend emits bad ProjectGuid value
When I tried generating a VS 2017 solution, all generated *.vcxproj contained this:

```
<PropertyGroup Label="Globals">
		<ProjectGuid>64FCBDC2-8B6E-45D3-AEE0-DA999A2C7A64</ProjectGuid>
</PropertyGroup>
```
Which then causes silent errors in visual studio 2017 IDE: project dont expand in solution explorer
 Reason - ProjectGuid value should contain brackets: 
`<ProjectGuid>{64FCBDC2-8B6E-45D3-AEE0-DA999A2C7A64}</ProjectGuid>`


Discussion:
Is this also how Guids should be in older versions of Visual Studio?
Yes

Resolving patch:
diff --git a/mesonbuild/backend/vs2010backend.py b/mesonbuild/backend/vs2010backend.py
--- a/mesonbuild/backend/vs2010backend.py
+++ b/mesonbuild/backend/vs2010backend.py
@@ -379,7 +379,7 @@ def create_basic_crap(self, target):
         pl.text = self.platform
         globalgroup = ET.SubElement(root, 'PropertyGroup', Label='Globals')
         guidelem = ET.SubElement(globalgroup, 'ProjectGuid')
-        guidelem.text = self.environment.coredata.test_guid
+        guidelem.text = '{%s}' % self.environment.coredata.test_guid
         kw = ET.SubElement(globalgroup, 'Keyword')
         kw.text = self.platform + 'Proj'
         p = ET.SubElement(globalgroup, 'Platform')
@@ -636,7 +636,7 @@ def gen_vcxproj(self, target, ofname, guid):
         # Globals
         globalgroup = ET.SubElement(root, 'PropertyGroup', Label='Globals')
         guidelem = ET.SubElement(globalgroup, 'ProjectGuid')
-        guidelem.text = guid
+        guidelem.text = '{%s}' % guid
         kw = ET.SubElement(globalgroup, 'Keyword')
         kw.text = self.platform + 'Proj'
         ns = ET.SubElement(globalgroup, 'RootNamespace')
@@ -1050,7 +1050,7 @@ def gen_regenproj(self, project_name, ofname):
         pl.text = self.platform
         globalgroup = ET.SubElement(root, 'PropertyGroup', Label='Globals')
         guidelem = ET.SubElement(globalgroup, 'ProjectGuid')
-        guidelem.text = self.environment.coredata.test_guid
+        guidelem.text = '{%s}' % self.environment.coredata.test_guid
         kw = ET.SubElement(globalgroup, 'Keyword')
         kw.text = self.platform + 'Proj'
         p = ET.SubElement(globalgroup, 'Platform')
@@ -1130,7 +1130,7 @@ def gen_testproj(self, target_name, ofname):
         pl.text = self.platform
         globalgroup = ET.SubElement(root, 'PropertyGroup', Label='Globals')
         guidelem = ET.SubElement(globalgroup, 'ProjectGuid')
-        guidelem.text = self.environment.coredata.test_guid
+        guidelem.text = '{%s}' % self.environment.coredata.test_guid
         kw = ET.SubElement(globalgroup, 'Keyword')
         kw.text = self.platform + 'Proj'
         p = ET.SubElement(globalgroup, 'Platform')


Test patch:
Repository: mesonbuild/meson

Issue:
The --help output for -D is ambiguous
When you run meson --help, it shows the following for -D.

-D PROJECTOPTIONS Set project options.

That's a little ambiguous because it implies that -D is only needed once to set multiple options but doesn't give any hint of how to set multiple options with one -D switch.


Discussion:

Resolving patch:
diff --git a/mesonbuild/mesonmain.py b/mesonbuild/mesonmain.py
--- a/mesonbuild/mesonmain.py
+++ b/mesonbuild/mesonmain.py
@@ -64,8 +64,8 @@ def add_builtin_argument(name, **kwargs):
 
 parser.add_argument('--cross-file', default=None,
                     help='File describing cross compilation environment.')
-parser.add_argument('-D', action='append', dest='projectoptions', default=[],
-                    help='Set project options.')
+parser.add_argument('-D', action='append', dest='projectoptions', default=[], metavar="option",
+                    help='Set the value of an option, can be used several times to set multiple options.')
 parser.add_argument('-v', '--version', action='version',
                     version=coredata.version)
                     # See the mesonlib.WrapMode enum for documentation


Test patch:
Repository: mesonbuild/meson

Issue:
mesontest isn't flushing stdout?
I'm using `ninja test` with a gitlab runner for CI. When the runner builds the code, I see the output get updated live. When the tests run, the output doesn't get flushed to the screen until after they are done - about 30 min worth of tests.

My guess is that `mesontest` isn't flushing it's stdout and it's being buffered by the system.

When the current test finishes, I'll rerun with `mesontest.py` changed to `#!/usr/bin/env python3
 -u` which should force unbuffered stdout.


Discussion:
Hmm changing to top of `mesontest.py` to `#!/usr/bin/env python3 -u` did not seem to help.
The printing happens on `mesontest` lines 294 and 296. It uses plain `print`. So it should just work. Dunno why that is.
I can't test this until tomorrow - but it's almost certainly related to the line in `build.ninja` not passing the `-u` flag to python3.

```
COMMAND = '/usr/bin/python3' '/usr/local/bin/mesontest' '--no-rebuild' '--print-errorlogs'
```

Or we could call `sys.stdout.flush()` after the `print` statements. Probably easier to modify the build.ninja file - I'll test tomorrow.

Resolving patch:
diff --git a/mesonbuild/backend/ninjabackend.py b/mesonbuild/backend/ninjabackend.py
--- a/mesonbuild/backend/ninjabackend.py
+++ b/mesonbuild/backend/ninjabackend.py
@@ -812,7 +812,7 @@ def generate_subdir_install(self, d):
     def generate_tests(self, outfile):
         self.serialize_tests()
         test_exe = get_meson_script(self.environment, 'mesontest')
-        cmd = [sys.executable, test_exe, '--no-rebuild']
+        cmd = [sys.executable, '-u', test_exe, '--no-rebuild']
         if not self.environment.coredata.get_builtin_option('stdsplit'):
             cmd += ['--no-stdsplit']
         if self.environment.coredata.get_builtin_option('errorlogs'):
@@ -824,7 +824,7 @@ def generate_tests(self, outfile):
         elem.write(outfile)
 
         # And then benchmarks.
-        cmd = [sys.executable, test_exe, '--benchmark', '--logbase',
+        cmd = [sys.executable, '-u', test_exe, '--benchmark', '--logbase',
                'benchmarklog', '--num-processes=1', '--no-rebuild']
         elem = NinjaBuildElement(self.all_outputs, 'benchmark', 'CUSTOM_COMMAND', ['all', 'PHONY'])
         elem.add_item('COMMAND', cmd)
diff --git a/mesontest.py b/mesontest.py
--- a/mesontest.py
+++ b/mesontest.py
@@ -1,4 +1,4 @@
-#!/usr/bin/env python3
+#!/usr/bin/env python3 -u
 
 # Copyright 2016 The Meson development team
 


Test patch:
Repository: mesonbuild/meson

Issue:
VS backend doesn't respect warning_level/--warnlevel
All generated VS projects use `/W1` regardless of warning level.

VisualStudioCPPCompiler correctly returns `'/W4'` for `get_warn_args('3')`, so it's clearly the backend that's failing to use it.

I'm currently trying to trace the problem in order to create a pull request for it.


Discussion:
OK, two discoveries:

VS 2010 through 2015 expect `<WarningLevel>` to go inside `<ClCompile>`.  The backend is generating the element, just in the wrong place.  **This may be the case for other elements as well.**

Additionally, vs2010backend.py simply appends the warning_level (which is `"1"`, `"2"`, or `"3"`) to `"Level"`, which results in a warning level one lower than the one specified in compilers.py (`/W2`, `/W3`, or `/W4`).  I'd assume that, between the two, we want the higher.

I will submit a PR presently.

Resolving patch:
diff --git a/mesonbuild/backend/vs2010backend.py b/mesonbuild/backend/vs2010backend.py
--- a/mesonbuild/backend/vs2010backend.py
+++ b/mesonbuild/backend/vs2010backend.py
@@ -706,9 +706,6 @@ def gen_vcxproj(self, target, ofname, guid):
             ET.SubElement(type_config, 'Optimization').text = 'MinSpace'
         elif '/Od' in o_flags:
             ET.SubElement(type_config, 'Optimization').text = 'Disabled'
-        # Warning level
-        warning_level = self.get_option_for_target('warning_level', target)
-        ET.SubElement(type_config, 'WarningLevel').text = 'Level' + warning_level
         # End configuration
         ET.SubElement(root, 'Import', Project='$(VCTargetsPath)\Microsoft.Cpp.props')
         generated_files, custom_target_output_files, generated_files_include_dirs = self.generate_custom_generator_commands(target, root)
@@ -862,6 +859,9 @@ def gen_vcxproj(self, target, ofname, guid):
         ET.SubElement(clconf, 'MinimalRebuild').text = 'true'
         ET.SubElement(clconf, 'FunctionLevelLinking').text = 'true'
         pch_node = ET.SubElement(clconf, 'PrecompiledHeader')
+        # Warning level
+        warning_level = self.get_option_for_target('warning_level', target)
+        ET.SubElement(clconf, 'WarningLevel').text = 'Level' + str(1 + int(warning_level))
         if self.get_option_for_target('werror', target):
             ET.SubElement(clconf, 'TreatWarningAsError').text = 'true'
         # Note: SuppressStartupBanner is /NOLOGO and is 'true' by default


Test patch:
Repository: mesonbuild/meson

Issue:
mesonintrospect --dependencies no longer works in 0.41.0
```
Traceback (most recent call last):
  File "/usr/bin/mesonintrospect", line 20, in <module>
    sys.exit(mintro.run(sys.argv[1:]))
  File "/usr/lib/python3.6/site-packages/mesonbuild/mintro.py", line 245, in run
    list_deps(coredata)
  File "/usr/lib/python3.6/site-packages/mesonbuild/mintro.py", line 162, in list_deps
    if d.found():
AttributeError: 'tuple' object has no attribute 'found'
```
Broke with 8cf29bd288cb67008a42a5c9503042f975c04a43 in which CoreData.deps was changed to an OrderedDict?



Discussion:

Resolving patch:
diff --git a/mesonbuild/mintro.py b/mesonbuild/mintro.py
--- a/mesonbuild/mintro.py
+++ b/mesonbuild/mintro.py
@@ -158,7 +158,7 @@ def list_buildsystem_files(coredata, builddata):
 
 def list_deps(coredata):
     result = []
-    for d in coredata.deps:
+    for d in coredata.deps.values():
         if d.found():
             args = {'compile_args': d.get_compile_args(),
                     'link_args': d.get_link_args()}


Test patch:
Repository: mesonbuild/meson

Issue:
New-line handling in if statements is silently dangerous.
Consider the following `if` statement:

```
if get_option('enable_alsa') == 'true'
	or (get_option('enable_alsa') == 'auto' and meson.get_compiler('cpp').has_header('alsa/asoundlib.h'))
```

The entire `or` clause is silently ignored. No errors or warnings, it just ignores it.

If I put it all one one line is fine, but that's kind of ugly. Does meson not support multi-line statements?


Discussion:
You can do multi line statements with the standard line continuation method of `\` at the end of line.

But that should produce an error because starting a statement with `or` should not be permitted...
Ah I see. That isn't mentioned in the [syntax page](http://mesonbuild.com/Syntax.html).

Funnily enough I thought the above should work because when I tested an `or` statement on its own it *did* give an error, and this didn't.

Resolving patch:
diff --git a/mesonbuild/mparser.py b/mesonbuild/mparser.py
--- a/mesonbuild/mparser.py
+++ b/mesonbuild/mparser.py
@@ -475,12 +475,18 @@ def e1(self):
     def e2(self):
         left = self.e3()
         while self.accept('or'):
+            if isinstance(left, EmptyNode):
+                raise ParseException('Invalid or clause.',
+                                     self.getline(), left.lineno, left.colno)
             left = OrNode(left, self.e3())
         return left
 
     def e3(self):
         left = self.e4()
         while self.accept('and'):
+            if isinstance(left, EmptyNode):
+                raise ParseException('Invalid and clause.',
+                                     self.getline(), left.lineno, left.colno)
             left = AndNode(left, self.e4())
         return left
 
@@ -633,6 +639,7 @@ def foreachblock(self):
     def ifblock(self):
         condition = self.statement()
         clause = IfClauseNode(condition.lineno, condition.colno)
+        self.expect('eol')
         block = self.codeblock()
         clause.ifs.append(IfNode(clause.lineno, clause.colno, condition, block))
         self.elseifblock(clause)


Test patch:
diff --git a/test cases/failing/57 or on new line/meson.build b/test cases/failing/57 or on new line/meson.build
new file mode 100644
--- /dev/null
+++ b/test cases/failing/57 or on new line/meson.build	
@@ -0,0 +1,7 @@
+project('silent_or', 'c')
+
+if get_option('foo') == 'true'
+        or get_option('foo') == 'auto'
+else
+        message('If this message is printed then something is wrong. The or above should give a syntax error.')
+endif
diff --git a/test cases/failing/57 or on new line/meson_options.txt b/test cases/failing/57 or on new line/meson_options.txt
new file mode 100644
--- /dev/null
+++ b/test cases/failing/57 or on new line/meson_options.txt	
@@ -0,0 +1 @@
+option('foo', type: 'combo', choices: ['true', 'false', 'auto'], value: 'auto')
Repository: mesonbuild/meson

Issue:
pthread function checking can't replicate a cmake check.
Hullo. Sorry if this question has been answered or if the proper way to do it is obvious and I'm blind.
I'm working on porting/creating a wrap for [openal-soft](https://github.com/kcat/openal-soft), getting
pretty far into it, but I'm having trouble replicating the following cmake snippet:
```cmake
CHECK_LIBRARY_EXISTS(pthread pthread_create "" HAVE_LIBPTHREAD)
IF(HAVE_LIBPTHREAD)
    SET(EXTRA_LIBS pthread ${EXTRA_LIBS})
ENDIF()
```
I've tried the following:
```meson
thread_dep = dependency('threads', required : false)
cc.has_function('pthread_create')
cc.has_function('pthread_create', dependencies : thread_dep)
cc.has_function('pthread_create', dependencies : thread_dep, prefix : '#include <pthread.h>')
```

Also, there is an odd snippet I've ran into in this same project which is like so:
```cmake
CHECK_SYMBOL_EXISTS(pthread_setname_np "pthread.h;pthread_np.h" HAVE_PTHREAD_SETNAME_NP)
```

Perhaps cc.has_header_symbol should be able to take an array of header strings? Seems some systems may require two headers to access certain functions.


Discussion:
> Perhaps cc.has_header_symbol should be able to take an array of header strings

You can already do this with the prefix keyword. Something like this:

    multiline_prefix = '''#include<pthread.h>
    #include<pthread_np.h>'''
    cc.has_function('pthread_create', dependencies : thread_dep, prefix : multiline_prefix)

Resolving patch:
diff --git a/mesonbuild/compilers/c.py b/mesonbuild/compilers/c.py
--- a/mesonbuild/compilers/c.py
+++ b/mesonbuild/compilers/c.py
@@ -273,9 +273,13 @@ def _get_compiler_check_args(self, env, extra_args, dependencies, mode='compile'
         for d in dependencies:
             # Add compile flags needed by dependencies
             args += d.get_compile_args()
+            if d.need_threads():
+                args += self.thread_flags()
             if mode == 'link':
                 # Add link flags needed to find dependencies
                 args += d.get_link_args()
+                if d.need_threads():
+                    args += self.thread_link_flags()
         # Select a CRT if needed since we're linking
         if mode == 'link':
             args += self.get_linker_debug_crt_args()


Test patch:
diff --git a/test cases/linuxlike/9 compiler checks with dependencies/meson.build b/test cases/linuxlike/9 compiler checks with dependencies/meson.build
--- a/test cases/linuxlike/9 compiler checks with dependencies/meson.build	
+++ b/test cases/linuxlike/9 compiler checks with dependencies/meson.build	
@@ -29,3 +29,10 @@ int main(int argc, char *argv[]) {
   assert (cc.has_function('deflate', prefix : '#include<zlib.h>', dependencies : zlib, name : 'Test for function in zlib'), 'has_function test failed.')
   assert (cc.links(linkcode, dependencies : zlib, name : 'Test link against zlib'), 'Linking test failed against zlib.')
 endif
+
+assert(cc.has_function('pthread_create',
+    dependencies : dependency('threads'),
+    prefix : '#include <pthread.h>'),
+  'Could not detect pthread_create with a thread dependency.')
+
+
Repository: mesonbuild/meson

Issue:
Invalid keywords warning does not say which target, meson.build file, or line/col number
> WARNING: Passed invalid keyword argument "install". This will become a hard error in the future.
> WARNING: Passed invalid keyword argument "install_dir". This will become a hard error in the future.

These warnings are quite useless because you have no idea what targets they are talking about. We should not release with this.


Discussion:

Resolving patch:
diff --git a/mesonbuild/interpreterbase.py b/mesonbuild/interpreterbase.py
--- a/mesonbuild/interpreterbase.py
+++ b/mesonbuild/interpreterbase.py
@@ -65,7 +65,9 @@ def __call__(self, f):
         def wrapped(s, node, args, kwargs):
             for k in kwargs:
                 if k not in self.permitted:
-                    mlog.warning('Passed invalid keyword argument "%s". This will become a hard error in the future.' % k)
+                    fname = os.path.join(s.subdir, environment.build_filename)
+                    mlog.warning('''Passed invalid keyword argument "%s" in %s line %d.
+This will become a hard error in the future.''' % (k, fname, s.current_lineno))
             return f(s, node, args, kwargs)
         return wrapped
 
@@ -101,6 +103,7 @@ def __init__(self, source_root, subdir):
         self.subdir = subdir
         self.variables = {}
         self.argument_depth = 0
+        self.current_lineno = -1
 
     def load_root_meson_file(self):
         mesonfile = os.path.join(self.source_root, self.subdir, environment.build_filename)
@@ -151,6 +154,7 @@ def evaluate_codeblock(self, node, start=0, end=None):
         while i < len(statements):
             cur = statements[i]
             try:
+                self.current_lineno = cur.lineno
                 self.evaluate_statement(cur)
             except Exception as e:
                 if not(hasattr(e, 'lineno')):


Test patch:
Repository: mesonbuild/meson

Issue:
phony and PHONY dirs cause bugs in Windows
In Windows having two directories with the same name breaks things. Git will report that your files have changed every time because it confuses `phony/meson.build` with `PHONY/meson.build`. 


Discussion:
Sigh, let's just remove that directory completely.

Resolving patch:
diff --git a/run_unittests.py b/run_unittests.py
--- a/run_unittests.py
+++ b/run_unittests.py
@@ -1288,6 +1288,9 @@ def test_all_forbidden_targets_tested(self):
         targets = mesonbuild.coredata.forbidden_target_names
         # We don't actually define a target with this name
         targets.pop('build.ninja')
+        # Remove this to avoid multiple entries with the same name
+        # but different case.
+        targets.pop('PHONY')
         for i in targets:
             self.assertPathExists(os.path.join(testdir, i))
 


Test patch:
diff --git a/test cases/common/159 reserved targets/PHONY/meson.build b/test cases/common/159 reserved targets/PHONY/meson.build
deleted file mode 100644
--- a/test cases/common/159 reserved targets/PHONY/meson.build	
+++ /dev/null
@@ -1 +0,0 @@
-executable('test-PHONY', '../test.c')
diff --git a/test cases/common/159 reserved targets/meson.build b/test cases/common/159 reserved targets/meson.build
--- a/test cases/common/159 reserved targets/meson.build	
+++ b/test cases/common/159 reserved targets/meson.build	
@@ -15,11 +15,10 @@ subdir('coverage-xml')
 subdir('dist')
 subdir('distcheck')
 subdir('install')
-# We end up creating duplicate lowercase target names for this on
-# case-insensitive HFS+, so disable it
-# https://travis-ci.org/mesonbuild/meson/jobs/264468097
-#subdir('phony')
-subdir('PHONY')
+# We don't have a 'PHONY' directory because Windows and OSX
+# choke horribly when there are two entries with the same
+# name but different case.
+subdir('phony')
 subdir('reconfigure')
 subdir('scan-build')
 subdir('test')
Repository: mesonbuild/meson

Issue:
meson rejects version numbers ending with a dot
From https://github.com/systemd/systemd/pull/5704#issuecomment-291959683
```sh
# Ubuntu Zesty Zapus (development branch)

Meson encountered an error in file meson.build, line 536, column 0:
Invalid version to compare against: '2.29.'; only numeric digits separated by "." are allowed: invalid literal for int() with base 10: ''

$ find /usr/lib -name '*.pc' | xargs grep -E 2.29
/usr/lib/x86_64-linux-gnu/pkgconfig/blkid.pc:Version: 2.29.
/usr/lib/x86_64-linux-gnu/pkgconfig/mount.pc:Version: 2.29.
/usr/lib/x86_64-linux-gnu/pkgconfig/uuid.pc:Version: 2.29.
```

@nirbheek wrote
> This is a mistake in util-linux, but it is also a valid pkg-config version, which follows the rpm version comparison rules. Meson barfs on this because we don't implement rpm version comparison bug-for-bug. Arguably, we should, or at least we should be a bit more resilient.


Discussion:
I am "fixing" util-linux to generate 2.29.0 on at least Ubuntu artful. Versions with trailing `.` compare fine with `dpkg --compare-versions`. Which logic is chosen on how to treat trailing `.` is irrelevant, as long as there is one.



Resolving patch:
diff --git a/mesonbuild/mesonlib.py b/mesonbuild/mesonlib.py
--- a/mesonbuild/mesonlib.py
+++ b/mesonbuild/mesonlib.py
@@ -255,7 +255,7 @@ def detect_vcs(source_dir):
 
 def grab_leading_numbers(vstr, strict=False):
     result = []
-    for x in vstr.split('.'):
+    for x in vstr.rstrip('.').split('.'):
         try:
             result.append(int(x))
         except ValueError as e:


Test patch:
Repository: mesonbuild/meson

Issue:
pkgconfig add URL parameter
Hello,
I have tried to add URL to pkg.generate in:
``` python
pkg = import('pkgconfig')
libs = ...     # the library/libraries users need to link against
h = ['.', ...] # subdirectories of ${prefix}/${includedir} to add to header path
pkg.generate(libraries : libs,
             subdirs : h,
             version : '1.0',
             name : 'libsimple',
             filebase : 'simple',
             description : 'A simple demo library.')
```
but there is error, so it seems that isn't supported yet ?

Any help appreciated


Discussion:
You can set arbitrary variables with `variables` kwarg, will that do?
Can you please provide simple usage or docs ?
I somehow figured it out, but it is appended before package info, can it be appended in package info ?
``` python
pkg = import('pkgconfig')
mylib = shared_library('byteconvert', 'ByteConvert.cpp', version : '0.1.2', soversion : '0',install: true)
install_headers('ByteConvert.hpp', subdir : 'ByteConvert')
pkg.generate(libraries : mylib,
             version : '0.1.2',
             name : 'libbyteconvert',
             filebase : 'libbyteconvert',
             description : 'A conversion library.',
             variables : 'URL=aa')

```
```
prefix=/usr/local
libdir=${prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include
URL=aa

Name: libbyteconvert
Description: A conversion library.
Version: 0.1.2
Libs: -L${libdir} -lbyteconvert
Cflags: -I${includedir}

```

Resolving patch:
diff --git a/mesonbuild/modules/pkgconfig.py b/mesonbuild/modules/pkgconfig.py
--- a/mesonbuild/modules/pkgconfig.py
+++ b/mesonbuild/modules/pkgconfig.py
@@ -121,7 +121,7 @@ def process_libs(self, libs):
 
     @permittedKwargs({'libraries', 'version', 'name', 'description', 'filebase',
                       'subdirs', 'requires', 'requires_private', 'libraries_private',
-                      'install_dir', 'extra_cflags', 'variables'})
+                      'install_dir', 'extra_cflags', 'variables', 'url'})
     def generate(self, state, args, kwargs):
         if len(args) > 0:
             raise mesonlib.MesonException('Pkgconfig_gen takes no positional arguments.')


Test patch: