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

Issue:
wrap-git's clone-recursive does not lead to submodules being updated to specified revision
When adding a subproject and specifying `clone-recursive = true` as well as `revision = somebranch`, meson will clone the git repository recursively and then checkout `somebranch`.  It will however not call `git submodule update` (or it would probably best to call `git submodule update --checkout --init --recursive`), leaving submodules of the cloned repository in the revision that `master` references them in.


Discussion:

Resolving patch:
diff --git a/mesonbuild/msubprojects.py b/mesonbuild/msubprojects.py
--- a/mesonbuild/msubprojects.py
+++ b/mesonbuild/msubprojects.py
@@ -92,7 +92,7 @@ def update_git(wrap, repo_dir, options):
                      '     To rebase your branch on top of', mlog.bold(revision), 'use', mlog.bold('--rebase'), 'option.')
             return
 
-    git(['submodule', 'update'], repo_dir)
+    git(['submodule', 'update', '--checkout', '--recursive'], repo_dir)
     git_show(repo_dir)
 
 def update_hg(wrap, repo_dir, options):
diff --git a/mesonbuild/wrap/wrap.py b/mesonbuild/wrap/wrap.py
--- a/mesonbuild/wrap/wrap.py
+++ b/mesonbuild/wrap/wrap.py
@@ -218,17 +218,16 @@ def get_file(self):
 
     def get_git(self):
         revno = self.wrap.get('revision')
-        if self.wrap.values.get('clone-recursive', '').lower() == 'true':
-            subprocess.check_call(['git', 'clone', '--recursive', self.wrap.get('url'),
-                                   self.directory], cwd=self.subdir_root)
-        else:
-            subprocess.check_call(['git', 'clone', self.wrap.get('url'),
-                                   self.directory], cwd=self.subdir_root)
+        subprocess.check_call(['git', 'clone', self.wrap.get('url'),
+                               self.directory], cwd=self.subdir_root)
         if revno.lower() != 'head':
             if subprocess.call(['git', 'checkout', revno], cwd=self.dirname) != 0:
                 subprocess.check_call(['git', 'fetch', self.wrap.get('url'), revno], cwd=self.dirname)
-                subprocess.check_call(['git', 'checkout', revno],
-                                      cwd=self.dirname)
+                subprocess.check_call(['git', 'checkout', revno], cwd=self.dirname)
+        if self.wrap.values.get('clone-recursive', '').lower() == 'true':
+            subprocess.check_call(['git', 'submodule', 'update',
+                                   '--init', '--checkout', '--recursive'],
+                                  cwd=self.dirname)
         push_url = self.wrap.values.get('push-url')
         if push_url:
             subprocess.check_call(['git', 'remote', 'set-url',


Test patch:
Repository: mesonbuild/meson

Issue:
0.50.0: test target: AttributeError: Can't get attribute 'ConfigData' on <module 'mesonbuild.coredata' from '/usr/lib/python3.7/site-packages/mesonbuild/coredata.py'>
<pre>+ /usr/bin/ninja test -v -j4 -C x86_64-redhat-linux-gnu
ninja: Entering directory `x86_64-redhat-linux-gnu&apos;
[0/1] /usr/bin/meson test --no-rebuild --print-errorlogs
Traceback (most recent call last):
  File &quot;/usr/lib/python3.7/site-packages/mesonbuild/mesonmain.py&quot;, line 122, in run
    return options.run_func(options)
  File &quot;/usr/lib/python3.7/site-packages/mesonbuild/mtest.py&quot;, line 1002, in run
    return th.doit()
  File &quot;/usr/lib/python3.7/site-packages/mesonbuild/mtest.py&quot;, line 753, in doit
    self.run_tests(tests)
  File &quot;/usr/lib/python3.7/site-packages/mesonbuild/mtest.py&quot;, line 888, in run_tests
    self.build_data = build.load(os.getcwd())
  File &quot;/usr/lib/python3.7/site-packages/mesonbuild/build.py&quot;, line 2307, in load
    obj = pickle.load(f)
AttributeError: Can&apos;t get attribute &apos;ConfigData&apos; on &lt;module &apos;mesonbuild.coredata&apos; from &apos;/usr/lib/python3.7/site-packages/mesonbuild/coredata.py&apos;&gt;
FAILED: meson-test 
/usr/bin/meson test --no-rebuild --print-errorlogs
ninja: build stopped: subcommand failed.
error: Bad exit status from /var/tmp/rpm-tmp.GduYpo (%check)
</pre>


Discussion:
Is this with a fresh build directory?
No, this looks like another bug with the rebuild for new version thing, I thought we caught those all...
I can replicate this using test case 192.

Resolving patch:
diff --git a/mesonbuild/build.py b/mesonbuild/build.py
--- a/mesonbuild/build.py
+++ b/mesonbuild/build.py
@@ -2307,8 +2307,13 @@ def load(build_dir):
             obj = pickle.load(f)
     except FileNotFoundError:
         raise MesonException(nonexisting_fail_msg)
-    except pickle.UnpicklingError:
+    except (pickle.UnpicklingError, EOFError):
         raise MesonException(load_fail_msg)
+    except AttributeError:
+        raise MesonException(
+            "Build data file {!r} references functions or classes that don't "
+            "exist. This probably means that it was generated with an old "
+            "version of meson. Try running meson {} --wipe".format(filename, build_dir))
     if not isinstance(obj, Build):
         raise MesonException(load_fail_msg)
     return obj


Test patch:
Repository: mesonbuild/meson

Issue:
i18n.merge_file() + build_by_default = warning
Meson 0.49.2 throws the following warnings when building GNOME Settings:

```
tests/interactive-panels/applications/meson.build:14: WARNING: Passed invalid keyword argument "build_by_default".
WARNING: This will become a hard error in the future.
```
Here's the snippet that triggers it:

```
desktop_files = [
  'dynamic-panel',
  'header-widget',
  'sidebar-widget',
  'static-init',
  'toplevel-sidebar-widget',
]

foreach desktop_file : desktop_files
  i18n.merge_file(
              desktop,
                type : 'desktop',
               input : 'gtp-@0@.desktop.in'.format(desktop_file),
              output : 'gnome-@0@-panel.desktop'.format(desktop_file),
              po_dir : po_dir,
    build_by_default : true,
             install : false,
  )
endforeach
```

Discussing on IRC, this is a buggy behavior, since i18n actually uses the `build_by_default` value, and yet warns about it.


Discussion:

Resolving patch:
diff --git a/mesonbuild/modules/i18n.py b/mesonbuild/modules/i18n.py
--- a/mesonbuild/modules/i18n.py
+++ b/mesonbuild/modules/i18n.py
@@ -64,8 +64,7 @@ def _get_data_dirs(state, dirs):
         return [path.join(src_dir, d) for d in dirs]
 
     @FeatureNew('i18n.merge_file', '0.37.0')
-    @permittedKwargs({'languages', 'data_dirs', 'preset', 'args', 'po_dir', 'type',
-                      'input', 'output', 'install', 'install_dir'})
+    @permittedKwargs(build.CustomTarget.known_kwargs | {'data_dirs', 'po_dir', 'type'})
     def merge_file(self, state, args, kwargs):
         podir = kwargs.pop('po_dir', None)
         if not podir:


Test patch:
Repository: mesonbuild/meson

Issue:
0.50.0 regression: gnome test does not install gresource file
As of 0.50.0, the `test cases/frameworks/7 gnome` project no longer installs the `simple-resources.gresource` file, causing the test to fail.

Building the same project (from the 0.50.0 tarball) with meson 0.49.2 installs the file, as expected.


Discussion:
glib 2.60.0
Arch Linux
With an older 2.58 glib it's fine as well, so this is a regression introduced by https://github.com/mesonbuild/meson/pull/4222.
Seems like with #4222 the `simple-resources.gresource` target is generated twice. If I move the [second](https://github.com/mesonbuild/meson/blob/master/test%20cases/frameworks/7%20gnome/resources/meson.build#L23) before `compile_resources` the [first](https://github.com/mesonbuild/meson/blob/master/test%20cases/frameworks/7%20gnome/resources/meson.build#L11) `compile_resources` the test passes with glib 2.60.0.

Resolving patch:
diff --git a/mesonbuild/modules/gnome.py b/mesonbuild/modules/gnome.py
--- a/mesonbuild/modules/gnome.py
+++ b/mesonbuild/modules/gnome.py
@@ -189,9 +189,13 @@ def compile_resources(self, state, args, kwargs):
                 gresource_ld_binary = True
 
         gresource = kwargs.pop('gresource_bundle', False)
-        if gresource or gresource_ld_binary:
+
+        if gresource:
             g_output = args[0] + '.gresource'
             g_name = args[0] + '_gresource'
+        elif gresource_ld_binary:
+            g_output = args[0] + '_ld_binary.gresource'
+            g_name = args[0] + '_ld_binary_gresource'
 
         output = args[0] + '.c'
         name = args[0] + '_c'
@@ -240,10 +244,7 @@ def compile_resources(self, state, args, kwargs):
         if gresource or gresource_ld_binary:
             target_g = GResourceTarget(g_name, state.subdir, state.subproject, g_kwargs)
             if gresource: # Only one target for .gresource files
-                if target_g.get_id() not in self.interpreter.build.targets:
-                    return ModuleReturnValue(target_g, [target_g])
-                else:
-                    return ModuleReturnValue(target_g, [])
+                return ModuleReturnValue(target_g, [target_g])
 
         target_c = GResourceTarget(name, state.subdir, state.subproject, kwargs)
 


Test patch:
Repository: mesonbuild/meson

Issue:
Rust: add_project_arguments doesn't seem to work?
See repo: https://github.com/ubsan/bitvec/blob/ffi/meson.build

Changing from using `bitvec_args` to `add_project_arguments('stuff', language: 'rust')` results in the rustc invocation:

```
rustc --crate-type dylib --crate-name bitvec -g --emit dep-info=bitvec.d --emit link -o libbitvec.so -C prefer-dynamic ../src/lib.rs
```

which is missing all of those arguments that I passed.


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
@@ -1193,6 +1193,8 @@ def generate_rust_target(self, target, outfile):
         args += ['--crate-name', target.name]
         args += rustc.get_buildtype_args(self.get_option_for_target('buildtype', target))
         args += rustc.get_debug_args(self.get_option_for_target('debug', target))
+        args += self.build.get_global_args(rustc, target.is_cross)
+        args += self.build.get_project_args(rustc, target.subproject, target.is_cross)
         depfile = os.path.join(target.subdir, target.name + '.d')
         args += ['--emit', 'dep-info={}'.format(depfile), '--emit', 'link']
         args += target.get_extra_args('rust')


Test patch:
Repository: mesonbuild/meson

Issue:
if-release probably should catch buildtype=plain



Discussion:
So, just to be clear, if you do `meson -Dn_debug=if-release -Dbuildtype=plain` you get assertions?
To answer my own question, yes that's exactly what happens. This seems like a bug to me.

Resolving patch:
diff --git a/mesonbuild/compilers/compilers.py b/mesonbuild/compilers/compilers.py
--- a/mesonbuild/compilers/compilers.py
+++ b/mesonbuild/compilers/compilers.py
@@ -510,7 +510,7 @@ def get_base_compile_args(options, compiler):
     try:
         if (options['b_ndebug'].value == 'true' or
                 (options['b_ndebug'].value == 'if-release' and
-                 options['buildtype'].value == 'release')):
+                 options['buildtype'].value in {'release', 'plain'})):
             args += ['-DNDEBUG']
     except KeyError:
         pass


Test patch:
Repository: mesonbuild/meson

Issue:
0.50.0 regression/feature: ERROR: Subdir keyword must not be an absolute path
Mutter is failing to configure with following error:

```
cogl/cogl/meson.build:513:0: ERROR: Subdir keyword must not be an absolute path.
```

I just did not see this in release-notes. If this is intentional, please add entry in release notes.


Discussion:
It's intentional: #5015
This should be a warning when the absolute path is also in the include dir.

Resolving patch:
diff --git a/mesonbuild/interpreter.py b/mesonbuild/interpreter.py
--- a/mesonbuild/interpreter.py
+++ b/mesonbuild/interpreter.py
@@ -612,7 +612,7 @@ def __init__(self, sources, kwargs):
         self.sources = sources
         self.install_subdir = kwargs.get('subdir', '')
         if os.path.isabs(self.install_subdir):
-            raise InterpreterException('Subdir keyword must not be an absolute path.')
+            mlog.deprecation('Subdir keyword must not be an absolute path. This will be a hard error in the next release.')
         self.custom_install_dir = kwargs.get('install_dir', None)
         self.custom_install_mode = kwargs.get('install_mode', None)
         if self.custom_install_dir is not None:


Test patch:
Repository: mesonbuild/meson

Issue:
0.50.0 regression: ERROR: "install_dir" must be a string
libwnck3 fails to build with:

```
meson.build:87:2: ERROR: "install_dir" must be a string
```

Everything what it does in meson.build seems to be legit:

```meson
foreach pc: [PACKAGE_NAME, PACKAGE_NAME + '-uninstalled']                                                     
  install_path = []                                                                                           
  if not pc.contains('-uninstalled')                                                                          
    install_path = join_paths(libdir, 'pkgconfig')                                                            
  endif                                                                                                       
  configure_file(input: pc + '.pc.in',                                                                        
    output: pc + '.pc',                                                                                       
    configuration: pc_conf,                                                                                   
    install_dir: install_path)                                                                                
endforeach                                                                                                    
```

Definitely it can be improved to always set install_path, and conditionally setting install: true/false..

But this is either regression or worth mentioning in release-notes.


Discussion:
~~It's intentional: #5015~~ Oops, meant to post on #5050.
This is a regression, we shouldn't break existing build files like this.

Resolving patch:
diff --git a/mesonbuild/interpreter.py b/mesonbuild/interpreter.py
--- a/mesonbuild/interpreter.py
+++ b/mesonbuild/interpreter.py
@@ -3634,7 +3634,12 @@ def func_configure_file(self, node, args, kwargs):
             mlog.deprecation('Please use the new `install:` kwarg instead of passing '
                              '`false` to `install_dir:`', location=node)
         if not isinstance(idir, str):
-            raise InterpreterException('"install_dir" must be a string')
+            if isinstance(idir, list) and len(idir) == 0:
+                mlog.deprecation('install_dir: kwarg must be a string and not an empty array. '
+                                 'Please use the install: kwarg to enable or disable installation. '
+                                 'This will be a hard error in the next release.')
+            else:
+                raise InterpreterException('"install_dir" must be a string')
         install = kwargs.get('install', idir != '')
         if not isinstance(install, bool):
             raise InterpreterException('"install" must be a boolean')


Test patch:
Repository: mesonbuild/meson

Issue:
ERROR: Cannot find frameworks with non-clang compiler
Building [ots](https://github.com/khaledhosny/ots) with meson 0.50.0 is failing with non-clang compilers, giving the following error:
```
meson.build:29:0: ERROR: Cannot find frameworks with non-clang compiler
```

The respective `meson.build` line has this:
```
coretext = dependency('appleframeworks', modules: 'applicationservices',        
                      required: false)
```

which used to work before with non-clang compilers (not find anything of course, which is fine). I don’t know why this was changed, but it looks like a breaking change to me.


Discussion:
The error should not be fatal when `required: false`. Will be fixed for the stable release.

Resolving patch:
diff --git a/mesonbuild/dependencies/base.py b/mesonbuild/dependencies/base.py
--- a/mesonbuild/dependencies/base.py
+++ b/mesonbuild/dependencies/base.py
@@ -2190,7 +2190,15 @@ def __init__(self, name, required, paths, env, lang, kwargs):
         if not self.clib_compiler:
             raise DependencyException('No C-like compilers are available')
         if self.system_framework_paths is None:
-            self.system_framework_paths = self.clib_compiler.find_framework_paths(self.env)
+            try:
+                self.system_framework_paths = self.clib_compiler.find_framework_paths(self.env)
+            except MesonException as e:
+                if 'non-clang' in str(e):
+                    # Apple frameworks can only be found (and used) with the
+                    # system compiler. It is not available so bail immediately.
+                    self.is_found = False
+                    return
+                raise
         self.detect(name, paths)
 
     def detect(self, name, paths):


Test patch:
Repository: mesonbuild/meson

Issue:
0.50.0 regression: Duplicated messages about "Appending XXXFLAGS from environment"
```
Appending CFLAGS from environment: '-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
Appending LDFLAGS from environment: '-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld'
Appending CFLAGS from environment: '-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection'
Appending LDFLAGS from environment: '-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld'
Native C compiler: cc (gcc 9.0.1 "cc (GCC) 9.0.1 20190227 (Red Hat 9.0.1-0.8)")
Appending LDFLAGS from environment: '-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld'
Appending LDFLAGS from environment: '-Wl,-z,relro -Wl,--as-needed  -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld'
Native Vala compiler: valac (valac 0.43.92)
```

This has happened to tracker.


Discussion:

Resolving patch:
diff --git a/mesonbuild/coredata.py b/mesonbuild/coredata.py
--- a/mesonbuild/coredata.py
+++ b/mesonbuild/coredata.py
@@ -531,7 +531,7 @@ def process_new_compilers(self, lang: str, comp, cross_comp, env):
         if cross_comp is not None:
             new_options_for_host = cross_comp.get_and_default_options(env.properties.host)
         else:
-            new_options_for_host = comp.get_and_default_options(env.properties.host)
+            new_options_for_host = new_options_for_build
 
         opts_machines_list = [
             (new_options_for_build, MachineChoice.BUILD),


Test patch:
Repository: mesonbuild/meson

Issue:
`run_command` target clash when invoked from subproject
Repro steps:
1. Create some script file in project root. E.g. `echo.sh`.
2. Create a subproject.
3. Put the following line in both root and subproject's `meson.build`: `run_command(meson.source_root()/'echo.sh', '123')`
4. Invoke project setup with ninja backend (`meson setup _build`)

Result: 
```
Multiple producers for Ninja target "../proj/echo.sh". Please rename your targets.
```

The error is also triggered when the command is present in two subprojects (i.e. not present in root). It works properly when the command is invoked form the same `meson.build`.


Discussion:
**Code causing the problem:**
https://github.com/mesonbuild/meson/blob/0ad56708955eaef47fcf854bbb00e9a0e54536c0/mesonbuild/interpreter.py#L2474 

**Explanation:**
When new files are added to `Interpreter::build_def_files` in the subproject (e.g. https://github.com/mesonbuild/meson/blob/0ad56708955eaef47fcf854bbb00e9a0e54536c0/mesonbuild/interpreter.py#L2343) they can't know anything about the parent project, which result in duplication check failure.

**Possible fix:**
Add deduplication in the problematic line.

**Things to care before applying the fix:**
Check that it's not possible to add clashing files to `build_def_files` from user side (that is from `meson.build`).




I can create a PR with the fix if someone can help me figure out the possibility of creating a clash in `build_def_files` from user-side.

Resolving patch:
diff --git a/mesonbuild/interpreter.py b/mesonbuild/interpreter.py
--- a/mesonbuild/interpreter.py
+++ b/mesonbuild/interpreter.py
@@ -2471,7 +2471,8 @@ def do_subproject(self, dirname, kwargs):
         self.active_projectname = current_active
         self.subprojects.update(subi.subprojects)
         self.subprojects[dirname] = SubprojectHolder(subi, self.subproject_dir, dirname)
-        self.build_def_files += subi.build_def_files
+        # Duplicates are possible when subproject uses files from project root
+        self.build_def_files = list(set(self.build_def_files + subi.build_def_files))
         self.build.merge(subi.build)
         self.build.subprojects[dirname] = subi.project_version
         return self.subprojects[dirname]


Test patch:
Repository: mesonbuild/meson

Issue:
LDFLAGS get passed to valac during sanity check
See: https://github.com/mesonbuild/meson/issues/5086#issuecomment-478881890 and later comments.


Discussion:

Resolving patch:
diff --git a/mesonbuild/compilers/compilers.py b/mesonbuild/compilers/compilers.py
--- a/mesonbuild/compilers/compilers.py
+++ b/mesonbuild/compilers/compilers.py
@@ -67,6 +67,8 @@
     clink_suffixes += lang_suffixes[_l]
 clink_suffixes += ('h', 'll', 's')
 
+# Languages that should use LDFLAGS arguments when linking.
+languages_using_ldflags = ('objcpp', 'cpp', 'objc', 'c', 'fortran', 'd', 'cuda')
 soregex = re.compile(r'.*\.so(\.[0-9]+)?(\.[0-9]+)?(\.[0-9]+)?$')
 
 # Environment variables that each lang uses.
@@ -976,6 +978,12 @@ def use_preproc_flags(self) -> bool:
         """
         return self.get_language() in {'c', 'cpp', 'objc', 'objcpp'}
 
+    def use_ldflags(self) -> bool:
+        """
+        Whether the compiler (or processes it spawns) cares about LDFLAGS
+        """
+        return self.get_language() in languages_using_ldflags
+
     def get_args_from_envvars(self):
         """
         Returns a tuple of (compile_flags, link_flags) for the specified language
@@ -1004,7 +1012,10 @@ def log_var(var, val: Optional[str]):
             compile_flags += shlex.split(env_compile_flags)
 
         # Link flags (same for all languages)
-        env_link_flags = os.environ.get('LDFLAGS')
+        if self.use_ldflags():
+            env_link_flags = os.environ.get('LDFLAGS')
+        else:
+            env_link_flags = None
         log_var('LDFLAGS', env_link_flags)
         if env_link_flags is not None:
             link_flags += shlex.split(env_link_flags)


Test patch: