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

Issue:
cc.has_header_symbol() not working reliable for strlcat
cc.has_header_symbol() is not working for strlcat with my setup (reports it found the symbol in the header although it's not defined there). I'm using clang 12 with gcc 11 libs on CentOS 8 Stream.
I guess this happens because the command calls the compiler which may not have -Werror=implicit-function-declaration set and thus only gives a warning but does not fail with an error code?


Discussion:
This works fine for me, e.g. I attempted to test for "strlcart" instead and it reported an error.

The check is for `strlcat`, not `strlcat()`, so it triggers a `warning: statement with no effect [-Wunused-value]` but isn't actually a function call so it doesn't trigger implicit-function-declaration.


Could you post builddir/meson-logs/meson-log.txt? It might have useful info in it (it will at least report the exact test file snippet used).
Here the requested log, see line 402 and the wrong result in 412:
[meson-log.txt](https://github.com/mesonbuild/meson/files/7048479/meson-log.txt)

Can be fixed by appending "-Werror=implicit-function-declaration" to CFLAGS, so I assume that should be done by meson itself?

Resolving patch:
diff --git a/mesonbuild/compilers/compilers.py b/mesonbuild/compilers/compilers.py
--- a/mesonbuild/compilers/compilers.py
+++ b/mesonbuild/compilers/compilers.py
@@ -1154,11 +1154,12 @@ def module_name_to_filename(self, module_name: str) -> str:
     def get_compiler_check_args(self, mode: CompileCheckMode) -> T.List[str]:
         """Arguments to pass the compiler and/or linker for checks.
 
-        The default implementation turns off optimizations. mode should be
-        one of:
+        The default implementation turns off optimizations.
 
         Examples of things that go here:
           - extra arguments for error checking
+          - Arguments required to make the compiler exit with a non-zero status
+            when something is wrong.
         """
         return self.get_no_optimization_args()
 
diff --git a/mesonbuild/compilers/mixins/clang.py b/mesonbuild/compilers/mixins/clang.py
--- a/mesonbuild/compilers/mixins/clang.py
+++ b/mesonbuild/compilers/mixins/clang.py
@@ -81,7 +81,11 @@ def get_pch_use_args(self, pch_dir: str, header: str) -> T.List[str]:
         return ['-include-pch', os.path.join(pch_dir, self.get_pch_name(header))]
 
     def get_compiler_check_args(self, mode: CompileCheckMode) -> T.List[str]:
-        myargs = []  # type: T.List[str]
+        # Clang is different than GCC, it will return True when a symbol isn't
+        # defined in a header. Specifically this seems ot have something to do
+        # with functions that may be in a header on some systems, but not all of
+        # them. `strlcat` specifically with can trigger this.
+        myargs: T.List[str] = ['-Werror=implicit-function-declaration']
         if mode is CompileCheckMode.COMPILE:
             myargs.extend(['-Werror=unknown-warning-option', '-Werror=unused-command-line-argument'])
             if mesonlib.version_compare(self.version, '>=3.6.0'):


Test patch:
Repository: mesonbuild/meson

Issue:
Get the i18n targets inside the meson files
I need to generate a file from the i18n *.gmo files. This `custom_target` needs to depend on the `<project_id>-gmo` target documented [here](https://mesonbuild.com/i18n-module.html).

This target should be retrievable through a method like :
```
gettext_targets = i18n.gettext('mypackage')
custom_target(
    depends: gettext_targets.target_gmo()
)
```

For now, I think the only way to achieve that is something like that :
```
ninja_gmo = custom_target(command: [ 'ninja', '-C' meson.build_root(), 'mypackage-gmo'])
```


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
@@ -143,6 +143,7 @@ def gettext(self, state, args, kwargs):
         datadirs = self._get_data_dirs(state, mesonlib.stringlistify(kwargs.get('data_dirs', [])))
         extra_args = mesonlib.stringlistify(kwargs.get('args', []))
         targets = []
+        gmotargets = []
 
         preset = kwargs.pop('preset', None)
         if preset:
@@ -185,6 +186,10 @@ def gettext(self, state, args, kwargs):
                           }
             gmotarget = build.CustomTarget(l+'.mo', path.join(state.subdir, l, 'LC_MESSAGES'), state.subproject, gmo_kwargs)
             targets.append(gmotarget)
+            gmotargets.append(gmotarget)
+
+        allgmotarget = build.AliasTarget(packagename + '-gmo', gmotargets, state.subdir, state.subproject)
+        targets.append(allgmotarget)
 
         updatepoargs = state.environment.get_build_command() + ['--internal', 'gettext', 'update_po', pkg_arg]
         if lang_arg:
@@ -196,7 +201,7 @@ def gettext(self, state, args, kwargs):
         updatepotarget = build.RunTarget(packagename + '-update-po', updatepoargs, [], state.subdir, state.subproject)
         targets.append(updatepotarget)
 
-        return ModuleReturnValue(None, targets)
+        return ModuleReturnValue([gmotargets, pottarget, updatepotarget], targets)
 
 def initialize(*args, **kwargs):
     return I18nModule(*args, **kwargs)


Test patch:
Repository: mesonbuild/meson

Issue:
Appleframeworks not detected with gcc-10 (homebrew installation) in Mac
Steps to reproduce:

1. create a project with a dependency on 'appleframeworks'.
2.  see it fail.

Gcc path does show the framework path:

```
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks
```

Also, adding `-framework Appkit` via link_args in replacement of real meson detection to target does find the framework and it works (workaround).




Discussion:
Real GCC (and vanilla clang) on macOS is currently a "best effort" situation, so this doesn't surprise me at all.
Which are supported in MacOS?
Apples clang fork is the only one in ci, so it's the only ones that has official support ATM. I'd be happy to review fixes for vanilla clang and gcc on macos, and add CI support of course

Resolving patch:
diff --git a/mesonbuild/compilers/mixins/clike.py b/mesonbuild/compilers/mixins/clike.py
--- a/mesonbuild/compilers/mixins/clike.py
+++ b/mesonbuild/compilers/mixins/clike.py
@@ -1177,9 +1177,7 @@ def find_framework(self, name: str, env: 'Environment', extra_dirs: T.List[str],
         Finds the framework with the specified name, and returns link args for
         the same or returns None when the framework is not found.
         '''
-        # TODO: maybe this belongs in clang? also, should probably check for macOS?
-        if self.id != 'clang':
-            raise mesonlib.MesonException('Cannot find frameworks with non-clang compiler')
+        # TODO: should probably check for macOS?
         return self._find_framework_impl(name, env, extra_dirs, allow_system)
 
     def get_crt_compile_args(self, crt_val: str, buildtype: str) -> T.List[str]:


Test patch:
Repository: mesonbuild/meson

Issue:
Failed subproject dependency on systems without git shows "Git program not found."
**Describe the bug**
On a system where builds happen in a sandbox with **no networking** with a subproject that's a git submodule the dependency will fail with
```
ERROR: Git program not found
```

which is highly confusing because it doesn't point to the exact issue at hand.

**To Reproduce**
I was building gnome-usage and the error pointed at this line https://gitlab.gnome.org/GNOME/gnome-usage/-/blob/master/meson.build#L22. The archive was not retrieved with submodules which was why meson was trying to call into `git`.

**Expected behavior**
An error that the submodule couldn't be retrieved would be much nicer.

**system parameters**
* what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.)
NixOS
* what Python version are you using e.g. 3.8.0
3.8.5
* what `meson --version`
0.55.1
* what `ninja --version` if it's a Ninja build
1.10.1



Discussion:

Resolving patch:
diff --git a/mesonbuild/wrap/wrap.py b/mesonbuild/wrap/wrap.py
--- a/mesonbuild/wrap/wrap.py
+++ b/mesonbuild/wrap/wrap.py
@@ -402,7 +402,7 @@ def get_file(self) -> None:
 
     def get_git(self) -> None:
         if not GIT:
-            raise WrapException('Git program not found.')
+            raise WrapException(f'Git program not found, cannot download {self.packagename}.wrap via git.')
         revno = self.wrap.get('revision')
         is_shallow = False
         depth_option = []    # type: T.List[str]


Test patch:
Repository: mesonbuild/meson

Issue:
Value "gnu89" (of type "string") for combo option "C language standard to use" is not one of the choices. Possible choices are (as string): "none", "c89", "c99", "c11", "c17", "gnu99", "gnu11".
Building glib2 2.62.6 with meson 0.59.1 fails:

```
Value "gnu89" (of type "string") for combo option "C language standard to use" is not one of the choices. Possible choices are (as string): "none", "c89", "c99", "c11", "c17", "gnu99", "gnu11".
```

With meson 0.58.1 there was no such error.

See https://trac.macports.org/ticket/63462

In #8766 gnu99 and gnu11 were added to the list of possible choices but for some reason gnu89 was not added? Could you add it, please?


Discussion:
Makes sense... the ones that were added got added due to https://github.com/mesonbuild/meson/commit/c54dd63547b030e3d9feee694ec6f49c434f0df8#r50842919

The request to add the GNU ones only called out some of the possible stds, and only those ones got added.

Would you like to submit a patch?
No, I would just like someone to fix it.

Resolving patch:
diff --git a/mesonbuild/compilers/objc.py b/mesonbuild/compilers/objc.py
--- a/mesonbuild/compilers/objc.py
+++ b/mesonbuild/compilers/objc.py
@@ -90,7 +90,7 @@ def get_options(self) -> 'coredata.KeyedOptionDictType':
         opts.update({
             OptionKey('std', machine=self.for_machine, lang='c'): coredata.UserComboOption(
                 'C language standard to use',
-                ['none', 'c89', 'c99', 'c11', 'c17', 'gnu99', 'gnu11'],
+                ['none', 'c89', 'c99', 'c11', 'c17', 'gnu89', 'gnu99', 'gnu11', 'gnu17'],
                 'none',
             )
         })
diff --git a/mesonbuild/compilers/objcpp.py b/mesonbuild/compilers/objcpp.py
--- a/mesonbuild/compilers/objcpp.py
+++ b/mesonbuild/compilers/objcpp.py
@@ -91,7 +91,7 @@ def get_options(self) -> 'coredata.KeyedOptionDictType':
         opts.update({
             OptionKey('std', machine=self.for_machine, lang='cpp'): coredata.UserComboOption(
                 'C++ language standard to use',
-                ['none', 'c++98', 'c++11', 'c++14', 'c++17'],
+                ['none', 'c++98', 'c++11', 'c++14', 'c++17', 'gnu++98', 'gnu++11', 'gnu++14', 'gnu++17'],
                 'none',
             )
         })


Test patch:
Repository: mesonbuild/meson

Issue:
configure_file not working with vs and layout=flat
**Describe the bug**
On a toy project following [the manual](https://mesonbuild.com/Configuration.html#a-full-example), using layout=flat on vs backend fails because the include path is incorrect.

**To Reproduce**
[meson_layout_flat.zip](https://github.com/mesonbuild/meson/files/5996320/meson_layout_flat.zip)
meson build --backend=vs --layout=flat

**Expected behavior**
compilation will fail with 'projconfig.h' : No such file or directory
while it compiles with meson build --backend=vs

**system parameters**
* native build
* windows 7 64bits
* Python 3.8.7
* `meson --version` = 0.56.2
* `ninja --version` = 1.10.2



Discussion:

Resolving patch:
diff --git a/mesonbuild/msetup.py b/mesonbuild/msetup.py
--- a/mesonbuild/msetup.py
+++ b/mesonbuild/msetup.py
@@ -177,8 +177,6 @@ def generate(self) -> None:
         mlog.initialize(env.get_log_dir(), self.options.fatal_warnings)
         if self.options.profile:
             mlog.set_timestamp_start(time.monotonic())
-        if env.coredata.options[mesonlib.OptionKey('backend')].value == 'xcode':
-            mlog.warning('xcode backend is currently unmaintained, patches welcome')
         with mesonlib.BuildDirLock(self.build_dir):
             self._generate(env)
 
@@ -264,6 +262,18 @@ def _generate(self, env: environment.Environment) -> None:
 
             # Post-conf scripts must be run after writing coredata or else introspection fails.
             intr.backend.run_postconf_scripts()
+
+            # collect warnings about unsupported build configurations; must be done after full arg processing
+            # by Interpreter() init, but this is most visible at the end
+            if env.coredata.options[mesonlib.OptionKey('backend')].value == 'xcode':
+                mlog.warning('xcode backend is currently unmaintained, patches welcome')
+            if env.coredata.options[mesonlib.OptionKey('layout')].value == 'flat':
+                mlog.warning('-Dlayout=flat is unsupported and probably broken. It was a failed experiment at '
+                             'making Windows build artifacts runnable while uninstalled, due to PATH considerations, '
+                             'but was untested by CI and anyways breaks reasonable use of conflicting targets in different subdirs. '
+                             'Please consider using `meson devenv` instead. See https://github.com/mesonbuild/meson/pull/9243 '
+                             'for details.')
+
         except Exception as e:
             mintro.write_meson_info_file(b, [e])
             if 'cdf' in locals():


Test patch:
Repository: mesonbuild/meson

Issue:
When `add_install_script` is used with `./` (curr.dir), the script may fail to run
**Describe the bug**

When using `meson.add_install_script('./test.sh')`, depending on the directory tree, it may happen that the script could not be run upon running later `ninja install` or `meson install`.

**To Reproduce**

```
 λ cat test.sh
#!/bin/bash
echo hello
 λ ./test.sh               # NOTE: the script itself runs fine
hello
 λ cat meson.build
project(
  'test',
  ['c'],
)
subdir('dir1/dir2/')
 λ cat dir1/dir2/meson.build
meson.add_install_script('./test.sh')
 λ meson build
The Meson build system
Version: 0.59.1
Source dir: /tmp/foo
Build dir: /tmp/foo/build
Build type: native build
Project name: test
Project version: undefined
C compiler for the host machine: ccache cc (gcc 11.1.0 "cc (GCC) 11.1.0")
C linker for the host machine: cc ld.bfd 2.36.1
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program ./test.sh found: YES (./test.sh)
Build targets in project: 0

Found ninja-1.10.2 at /usr/bin/ninja
 λ DESTDIR=/tmp/ ninja -C build install
ninja: Entering directory `build'
[0/1] Installing files.
Running custom install script './test.sh'
FAILED: install script './test.sh' could not be run, stopped
FAILED: meson-install
/usr/bin/meson install --no-rebuild
ninja: build stopped: subcommand failed.
```

**Expected behavior**

The last command would succeed

**Known Workarounds**

With the directory tree here, if script is used as `meson.add_install_script('../../test.sh')`, then there will be no errors upon installation.

**system parameters**
* Is this a [cross build](https://mesonbuild.com/Cross-compilation.html) or just a plain native build ? Native
* OS: Archlinux
* Python version: 3.9.6
* `meson --version`: 0.59.1
* `ninja --version`: 1.10.2



Discussion:
The documented lookup order for find_program and by extension add_install_script states that for lookup inside the project source tree, only ../../test.sh shall be found from the subdir, never `./test.sh` unless the find_program or add_install_script is in the meson.build from the same directory as the test.sh file.

The only bug here is that apparently it ever successfully reported that it found test.sh

Resolving patch:
diff --git a/mesonbuild/programs.py b/mesonbuild/programs.py
--- a/mesonbuild/programs.py
+++ b/mesonbuild/programs.py
@@ -295,6 +295,9 @@ def _search(self, name: str, search_dir: T.Optional[str]) -> T.List[T.Optional[s
         commands = self._search_dir(name, search_dir)
         if commands:
             return commands
+        # If there is a directory component, do not look in PATH
+        if os.path.dirname(name) and not os.path.isabs(name):
+            return [None]
         # Do a standard search in PATH
         path = os.environ.get('PATH', None)
         if mesonlib.is_windows() and path:


Test patch:
Repository: mesonbuild/meson

Issue:
Support "cpp_std=c++20" for Windows Visual Studio backend
**Describe the bug**
Since [Visual Studio 2019 v16.11](https://docs.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-160#c-standards-support), it supports C++20 standard. However, when using "cpp_std=c++20", I get error: Value "c++20" (of type "string") for combo option "C++ language standard to use" is not one of the choices. Possible choices are (as string): "none", "c++11", "vc++11", "c++14", "c++latest", "vc++latest", "vc++14", "c++17", "vc++17".

**To Reproduce**
meson.build:
```
project(
    'my_project',
    'cpp',
    default_options : ['cpp_std=c++latest']
)
```

**Expected behavior**
`meson builddir` should complete without error

**system parameters**
* Is this a [cross build](https://mesonbuild.com/Cross-compilation.html) or just a plain native build (for the same computer)? No
* what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.): Windows 10
* what Python version are you using e.g. 3.8.0: 3.9.7
* what `meson --version`: 0.59.1
* what `ninja --version` if it's a Ninja build: 1.10.2



Discussion:

Resolving patch:
diff --git a/mesonbuild/compilers/cpp.py b/mesonbuild/compilers/cpp.py
--- a/mesonbuild/compilers/cpp.py
+++ b/mesonbuild/compilers/cpp.py
@@ -598,10 +598,12 @@ class VisualStudioLikeCPPCompilerMixin(CompilerMixinBase):
         'vc++11': (True, 11),
         'vc++14': (True, 14),
         'vc++17': (True, 17),
+        'vc++20': (True, 20),
         'vc++latest': (True, "latest"),
         'c++11': (False, 11),
         'c++14': (False, 14),
         'c++17': (False, 17),
+        'c++20': (False, 20),
         'c++latest': (False, "latest"),
     }
 
@@ -703,6 +705,8 @@ def get_options(self) -> 'KeyedOptionDictType':
         # Visual Studio 2017 and later
         if version_compare(self.version, '>=19.11'):
             cpp_stds.extend(['vc++14', 'c++17', 'vc++17'])
+        if version_compare(self.version, '>=19.29'):
+            cpp_stds.extend(['c++20', 'vc++20'])
         return self._get_options_impl(super().get_options(), cpp_stds)
 
     def get_option_compile_args(self, options: 'KeyedOptionDictType') -> T.List[str]:


Test patch:
Repository: mesonbuild/meson

Issue:
regression in adding machine info to a dictionary
```
$ git clone https://github.com/mesonbuild/wrapdb
$ cd wrapdb
$ meson setup builddir/ -Dwraps=cmocka
[...]
subprojects/cmocka-1.1.5/meson.build:54:2: ERROR: Object <MachineInfo: linux x86_64 (x86_64)> of type MachineInfo is neither in self.holder_map nor self.bound_holder_map.

    This is a Meson bug and should be reported!
```

Offending code:
```
cc_dict = {
    'compiler': meson.get_compiler('c'),
    'machine': host_machine,
    'config_h_subdir': 'private',
    'native': false
}

cc_native_dict = {
    'compiler': meson.get_compiler('c', native: true),
    'machine': build_machine,
    'config_h_subdir': 'private_native',
    'native': true
}

configurations = [cc_dict, cc_native_dict]

foreach entry : configurations
  compiler = entry.get('compiler')
  is_native = entry.get('native')
  machine = entry.get('machine')      # <<<<<< meson bug
```

This is fallout from commit af0587cb490dfa2c2a00c2426c10d1de11d34fdd


Discussion:

Resolving patch:
diff --git a/mesonbuild/interpreter/interpreter.py b/mesonbuild/interpreter/interpreter.py
--- a/mesonbuild/interpreter/interpreter.py
+++ b/mesonbuild/interpreter/interpreter.py
@@ -19,6 +19,7 @@
 from .. import build
 from .. import optinterpreter
 from .. import compilers
+from .. import envconfig
 from ..wrap import wrap, WrapMode
 from .. import mesonlib
 from ..mesonlib import MesonBugException, HoldableObject, FileMode, MachineChoice, OptionKey, listify, extract_as_list, has_path_sep
@@ -419,6 +420,7 @@ def build_holder_map(self) -> None:
             compilers.RunResult: compilerOBJ.TryRunResultHolder,
             dependencies.ExternalLibrary: OBJ.ExternalLibraryHolder,
             coredata.UserFeatureOption: OBJ.FeatureOptionHolder,
+            envconfig.MachineInfo: OBJ.MachineHolder,
         })
 
         '''


Test patch:
diff --git a/test cases/common/188 dict/meson.build b/test cases/common/188 dict/meson.build
--- a/test cases/common/188 dict/meson.build	
+++ b/test cases/common/188 dict/meson.build	
@@ -69,3 +69,14 @@ assert(d[k2] == 2, 'Incorrect expression evaluation in dictionary key')
 d = {'a' + 'b' : 1}
 assert(d['a' + 'b'] == 1, 'Incorrect expression evaluation in dictionary key')
 assert(d['ab'] == 1, 'Incorrect expression evaluation in dictionary key')
+
+# Complex types
+d = {
+  'sanity': 1,
+  'host': host_machine,
+  'meson': meson,
+}
+
+assert(d['sanity'] == 1)
+assert(not is_disabler(d['meson']))
+assert(not is_disabler(d['host']))
Repository: mesonbuild/meson

Issue:
meson does not search CMake user package registry
**Describe the bug**
Users can install CMake packages into the user package registry (`$HOME/.cmake/packages` on Unix by default). CMake will check this directory for packages if a package isn't found on the system, but meson does not.

**To Reproduce**

The following works with plain CMake:

```bash
$ mkdir -p ~/.cmake/packages/Foo
$ echo "$HOME/cmake/foo" > ~/.cmake/packages/Foo/foo
$ mkdir -p ~/cmake/foo
$ touch ~/cmake/foo/FooConfig.cmake
$ mkdir -p ~/cmake/bar
$ cd ~/cmake/bar
$ cat >CMakeLists.txt <<EOF
project(bar)
find_package(Foo REQUIRED)
EOF
$ cd ~/cmake/bar
$ mkdir build
$ cd build
$ cmake ..
```

Now trying to use the `Foo` package from meson:

```bash
$ mkdir ~/meson/bar
$ cd ~/meson/bar
$ cat > meson.build <<EOF
project('bar', 'c')

foo = dependency('Foo')
EOF
$ meson build
```

meson cannot find `Foo`.

**Expected behavior**
meson searches the CMake user package registry for CMake packages.

**system parameters**
* macOS Big Sur
* Python 3.9.7
* meson 0.59.2


Discussion:

Resolving patch:
diff --git a/mesonbuild/dependencies/cmake.py b/mesonbuild/dependencies/cmake.py
--- a/mesonbuild/dependencies/cmake.py
+++ b/mesonbuild/dependencies/cmake.py
@@ -346,6 +346,12 @@ def search_lib_dirs(path: str) -> bool:
         if env_path and find_module(env_path):
             return True
 
+        # Check the Linux CMake registry
+        linux_reg = Path.home() / '.cmake' / 'packages'
+        for p in [linux_reg / name, linux_reg / lname]:
+            if p.exists():
+                return True
+
         return False
 
     def _detect_dep(self, name: str, package_version: str, modules: T.List[T.Tuple[str, bool]], components: T.List[T.Tuple[str, bool]], args: T.List[str]) -> None:


Test patch: