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

Issue:
Certain Fortran targets are always considered out of date
**Describe the bug**
In some situations ninja re-builds Fortran targets that do not need to get rebuild.

**To Reproduce**
```
$ cd "test cases/fortran/3 module procedure"
$ meson setup build
$ ninja -C build
ninja: Entering directory `build'
[3/3] Linking target use_syntax
$ ninja -C build
ninja: Entering directory `build'
ninja: no work to do.
$ touch use_syntax.f90 
$ ninja -C build/
ninja: Entering directory `build/'
[2/2] Linking target use_syntax
$ ninja -C build/
ninja: Entering directory `build/'
[2/2] Linking target use_syntax
$ ninja -C build/
ninja: Entering directory `build/'
[2/2] Linking target use_syntax
```

**Expected behavior**
Executing ninja twice should give "ninja: no work to do."

**system parameters**
* Native Build
* Arch Linux
* Python 3.10.10
* meson 1.0.1
* ninja 1.11.1



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
@@ -2375,8 +2375,12 @@ def generate_compile_rule_for(self, langname, compiler):
             self.generate_cython_compile_rules(compiler)
             return
         crstr = self.get_rule_suffix(compiler.for_machine)
+        options = self._rsp_options(compiler)
         if langname == 'fortran':
             self.generate_fortran_dep_hack(crstr)
+            # gfortran does not update the modification time of *.mod files, therefore restat is needed.
+            # See also: https://github.com/ninja-build/ninja/pull/2275
+            options['extra'] = 'restat = 1'
         rule = self.compiler_to_rule_name(compiler)
         depargs = NinjaCommandArg.list(compiler.get_dependency_gen_args('$out', '$DEPFILE'), Quoting.none)
         command = compiler.get_exelist()
@@ -2388,7 +2392,6 @@ def generate_compile_rule_for(self, langname, compiler):
         else:
             deps = 'gcc'
             depfile = '$DEPFILE'
-        options = self._rsp_options(compiler)
         self.add_rule(NinjaRule(rule, command, args, description, **options,
                                 deps=deps, depfile=depfile))
 


Test patch:
Repository: mesonbuild/meson

Issue:
No such file or directory: 'C:\\Program Files\\Meson\\mesonbuild\\scripts\\python_info.py'
### Discussed in https://github.com/mesonbuild/meson/discussions/11688

<div type='discussions-op-text'>

<sup>Originally posted by **KyrietS** April 15, 2023</sup>
Hi,

I tried compiling Cairo but when I ran `meson setup build/` I got an error:

```
meson.build:111:27: ERROR: <PythonExternalProgram 'python3' -> ['C:\\Program Files\\Meson\\meson.exe', 'runpython']> is not a valid python or it is missing distutils
```

Inside `build/meson-logs/meson-log.txt` I can see:

```
Program stderr:

Traceback (most recent call last):
  File "mesonbuild\mesonmain.py", line 194, in run
  File "mesonbuild\mesonmain.py", line 149, in run_runpython_command
  File "runpy.py", line 288, in run_path
  File "runpy.py", line 252, in _get_code_from_file
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Program Files\\Meson\\mesonbuild\\scripts\\python_info.py'
```

My specs:
* Windows 11
* Python 3.11.3
* Meson 1.1.0
</div>


Discussion:

Resolving patch:
diff --git a/mesonbuild/utils/universal.py b/mesonbuild/utils/universal.py
--- a/mesonbuild/utils/universal.py
+++ b/mesonbuild/utils/universal.py
@@ -176,8 +176,8 @@ class _VerPickleLoadable(Protocol):
 
 from glob import glob
 
-if os.path.basename(sys.executable) == 'meson.exe':
-    # In Windows and using the MSI installed executable.
+if getattr(sys, 'frozen', False) and hasattr(sys, '_MEIPASS'):
+    # using a PyInstaller bundle, e.g. the MSI installed executable
     python_command = [sys.executable, 'runpython']
 else:
     python_command = [sys.executable]
diff --git a/packaging/hook-mesonbuild.py b/packaging/hook-mesonbuild.py
--- a/packaging/hook-mesonbuild.py
+++ b/packaging/hook-mesonbuild.py
@@ -21,7 +21,7 @@ def get_all_modules_from_dir(dirname):
     modules = ['mesonbuild.' + modname + '.' + x for x in modules if not x.startswith('_')]
     return modules
 
-datas += collect_data_files('mesonbuild.scripts')
+datas += collect_data_files('mesonbuild.scripts', include_py_files=True, excludes=['**/__pycache__'])
 datas += collect_data_files('mesonbuild.cmake.data')
 datas += collect_data_files('mesonbuild.dependencies.data')
 


Test patch:
Repository: mesonbuild/meson

Issue:
docs: Document buildtarget.get_id() [skip ci]



Discussion:
I feel a bit bad about this one. `get_id` is a poor name, dunno what I was thinking about there. Maybe it was supposed to be only an internal method and not actually exposed to the public (does not make the name any better). Should this be properly hidden instead, I'd imagine most people would use `private_dir_include` instead?
@jpakkane, someone's using it: https://github.com/mesonbuild/meson/issues/5995

Maybe it would be better to alias it and mark `get_id` as deprecated?
> @jpakkane, someone's using it: #5995

I'm just evaluating Meson for now, don't count me as an actual user. No one should be using undocumented APIs :-)

BTW using `get_id()` in `configure_file()` is actually harder than I thought *if* you want proper dependencies because of an obvious circular... dependency. I found this hardcoding workaround + mitigation with an `assert`.  Any better idea to break the circular dependency?

```
# Can't call myexe.get_id() yet because myexe doesn't exist yet
myexe_id = 'myexe.elf@exe' #  myexe.get_id()     #    <= circular dependency
# https://github.com/mesonbuild/meson/pull/291
objs_dir = '?'.join(myexe_id.split('@')) + '/'

ld_template = 'template.ld'
ld_script   = 'script.ld'

generated_ld_script = configure_file(
  input: ld_template,
  output: ld_script,
  configuration : { 'OBJSDIR': objs_dir },      #     <= circular dependency
)

myexe = executable(
   'foo.S', 'bar.c',
   ...
   link_args : [ ..., '-Wl,--script=' + ld_script ],
   link_depends: generated_ld_script,          #     <= circular dependency
)

assert(myexe_id == myexe.get_id(),
       'myexe has changed name, you must update myexe_id')
```

template.ld
```
SECTIONS
{
	.text : {
		@OBJSDIR@foo.S.obj(.text)
  ...
```

This seems to have gotten lost in the dust too. What is the status of this method? Does it still exist?
It exists and still should not be used any more than it ever should have. :D
Since it seems like Meson has gone down the "if it isn't documented" it isn't stable route, then we could just close this and maybe remove the method? It isn't clear if that is the path that should be taken or it should simply be renamed.

Resolving patch:
diff --git a/mesonbuild/interpreter/interpreterobjects.py b/mesonbuild/interpreter/interpreterobjects.py
--- a/mesonbuild/interpreter/interpreterobjects.py
+++ b/mesonbuild/interpreter/interpreterobjects.py
@@ -887,6 +887,9 @@ def extract_all_objects_method(self, args: T.List[TYPE_nvar], kwargs: 'kwargs.Bu
 
     @noPosargs
     @noKwargs
+    @FeatureDeprecated('BuildTarget.get_id', '1.2.0',
+                       'This was never formally documented and does not seem to have a real world use. ' +
+                       'See https://github.com/mesonbuild/meson/pull/6061')
     def get_id_method(self, args: T.List[TYPE_var], kwargs: TYPE_kwargs) -> str:
         return self._target_object.get_id()
 


Test patch:
Repository: mesonbuild/meson

Issue:
fix deps cache always invalidated



Discussion:

Resolving patch:
diff --git a/mesonbuild/coredata.py b/mesonbuild/coredata.py
--- a/mesonbuild/coredata.py
+++ b/mesonbuild/coredata.py
@@ -704,12 +704,6 @@ def replace(v):
 
         if key.name == 'buildtype':
             dirty |= self._set_others_from_buildtype(value)
-        elif key.name in {'wrap_mode', 'force_fallback_for'}:
-            # We could have the system dependency cached for a dependency that
-            # is now forced to use subproject fallback. We probably could have
-            # more fine-grained cache invalidation, but better be safe.
-            self.clear_deps_cache()
-            dirty = True
 
         return dirty
 
diff --git a/mesonbuild/interpreter/dependencyfallbacks.py b/mesonbuild/interpreter/dependencyfallbacks.py
--- a/mesonbuild/interpreter/dependencyfallbacks.py
+++ b/mesonbuild/interpreter/dependencyfallbacks.py
@@ -220,6 +220,8 @@ def _get_cached_dep(self, name: str, kwargs: TYPE_nkwargs) -> T.Optional[Depende
                 mlog.log('Dependency', mlog.bold(self._display_name),
                          'found:', mlog.red('NO'), *info)
                 return cached_dep
+        elif self.forcefallback and self.subproject_name:
+            cached_dep = None
         else:
             info = [mlog.blue('(cached)')]
             cached_dep = self.coredata.deps[for_machine].get(identifier)


Test patch:
Repository: mesonbuild/meson

Issue:
Meson cannot detect the correct windres executable for MSVS's stock Clang
**Describe the bug**

Meson believes that `windres` is the only available Windows resource compiler when GCC or Clang are the active compiler.

https://github.com/mesonbuild/meson/blob/e20717ed8f9f746a233e2bd2b3018997a3f73799/mesonbuild/modules/windows.py#L85-L92

This is almost correct, except that it's *not* for the Clang that Microsoft Visual Studio ships. It's unique in that it does not ship windres, but rather relies on MSVC's `rc` executable that comes with the stock compiler.

Basically, the check above needs to e.g. validate if `_MSC_VER` is present in the compiler before bailing over to finding `windres`. Just relying on the compiler ID is not reliable to determine the ABI.

**To Reproduce**

In a Windows box with Visual Studio 2022 and LLVM installed,

![imagen](https://github.com/mesonbuild/meson/assets/13498015/9807f77d-00e8-4515-9170-b284c0422ae5)

ensure that in your environment or native file, the `CC` and `CXX` variables are set to `clang` . Then try to build https://github.com/bad-alloc-heavy-industries/substrate:

```
git clone https://github.com/bad-alloc-heavy-industries/substrate
cd substrate
meson setup build --buildtype debugoptimized
```

**Expected behavior**

It will fail out of the box with:

```
impl\meson.build:177:29: ERROR: Could not find Windows resource compiler
```

This can be worked around with setting the `WINDRES` environment variable to `rc`.

**system parameters**
* Is this a [cross build](https://mesonbuild.com/Cross-compilation.html) or just a plain native build (for the same computer)?
  * Native build
* what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.)
  * Windows 10 22H2
* what Python version are you using e.g. 3.8.0
  * Python 3.10.7
* what `meson --version`
  * 1.1.0
* what `ninja --version` if it's a Ninja build
  * 1.10.2



Discussion:
@amyspark can you submit a PR for this? Should be easy. Plus you have a system which can easily test the changes.
@tristan957 Sure, though I'm not sure yet if Meson's internals allow compiler ABI reflection.

Resolving patch:
diff --git a/mesonbuild/modules/windows.py b/mesonbuild/modules/windows.py
--- a/mesonbuild/modules/windows.py
+++ b/mesonbuild/modules/windows.py
@@ -86,7 +86,8 @@ def _find_resource_compiler(self, state: 'ModuleState') -> T.Tuple[ExternalProgr
 
         if not rescomp or not rescomp.found():
             comp = self.detect_compiler(state.environment.coredata.compilers[for_machine])
-            if comp.id in {'msvc', 'clang-cl', 'intel-cl'}:
+            if comp.id in {'msvc', 'clang-cl', 'intel-cl'} or (comp.linker and comp.linker.id in {'link', 'lld-link'}):
+                # Microsoft compilers uses rc irrespective of the frontend
                 rescomp = ExternalProgram('rc', silent=True)
             else:
                 rescomp = ExternalProgram('windres', silent=True)


Test patch:
Repository: mesonbuild/meson

Issue:
armar compatibility broken
With commit b4d9b2551c32288754a3008d14895c6fe53f48e2 the armar compatibility was broken.

I have armar specified as static linker in my cross file. Meson setup now gives me the following error:
ERROR: Unknown linker(s): [['armar']]

The issue is that in detect_static_linker the '-?' parameter is passed into armar which causes it to print an error, the standard help and exit with exit code 1. It should either be called without any parameters or with the '--version' parameter.


Discussion:
CC @mon 
Cheers for the ping. Seems like just using binary names is fragile after all, and we need to use something similar to the compiler detection where version flags are tried if some fail. I'll try and hurry through #11421 (it's been stalled waiting for changes from me) and then make a fix.

Resolving patch:
diff --git a/mesonbuild/compilers/detect.py b/mesonbuild/compilers/detect.py
--- a/mesonbuild/compilers/detect.py
+++ b/mesonbuild/compilers/detect.py
@@ -204,8 +204,6 @@ def detect_static_linker(env: 'Environment', compiler: Compiler) -> StaticLinker
 
         if any(os.path.basename(x) in {'lib', 'lib.exe', 'llvm-lib', 'llvm-lib.exe', 'xilib', 'xilib.exe'} for x in linker):
             arg = '/?'
-        elif linker_name in {'ar2000', 'ar2000.exe', 'ar430', 'ar430.exe', 'armar', 'armar.exe'}:
-            arg = '?'
         else:
             arg = '--version'
         try:
@@ -234,7 +232,7 @@ def detect_static_linker(env: 'Environment', compiler: Compiler) -> StaticLinker
             return linkers.CcrxLinker(linker)
         if out.startswith('GNU ar') and 'xc16-ar' in linker_name:
             return linkers.Xc16Linker(linker)
-        if 'Texas Instruments Incorporated' in out:
+        if "-->  error: bad option 'e'" in err: # TI
             if 'ar2000' in linker_name:
                 return linkers.C2000Linker(linker)
             else:


Test patch:
Repository: mesonbuild/meson

Issue:
macOS: LD version detection not working with Xcode 15.0 beta 3
The linker version detection happens here: https://github.com/mesonbuild/meson/blob/master/mesonbuild/linkers/detect.py#L197C6-L197C6

```python
        for line in newerr.split('\n'):
            if 'PROJECT:ld' in line:
                v = line.split('-')[1]
                break
```

However, the latest Xcode 15.0 beta 3 outputs this:

```
@(#)PROGRAM:ld  PROJECT:dyld-1009.5
BUILD 20:45:24 Jun 29 2023
configured to support archs: i386 x86_64 x86_64h armv6 armv7 armv7s armv7m armv7k arm64 arm64e arm64_32
LTO support using: LLVM version 15.0.0 (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.0.12)
Library search paths:
Framework search paths:
ld: Undefined symbols:
  _main, referenced from:

clang: error: linker command failed with exit code 1 (use -v to see invocation)
```

Compare this with Xcode 14.3.1:

```
@(#)PROGRAM:ld  PROJECT:ld64-857.1
BUILD 23:13:29 May  7 2023
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
Library search paths:
Framework search paths:
Undefined symbols for architecture arm64:
  "_main", referenced from:
     implicit entry/start for main executable
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```

As you can see, the project name changed from `PROJECT:ld` to `PROJECT:dyld` and the detection code no longer works.



Discussion:

Resolving patch:
diff --git a/mesonbuild/linkers/detect.py b/mesonbuild/linkers/detect.py
--- a/mesonbuild/linkers/detect.py
+++ b/mesonbuild/linkers/detect.py
@@ -194,7 +194,7 @@ def guess_nix_linker(env: 'Environment', compiler: T.List[str], comp_class: T.Ty
         _, newo, newerr = Popen_safe_logged(cmd, msg='Detecting Apple linker via')
 
         for line in newerr.split('\n'):
-            if 'PROJECT:ld' in line:
+            if 'PROJECT:ld' in line or 'PROJECT:dyld' in line:
                 v = line.split('-')[1]
                 break
         else:


Test patch:
Repository: mesonbuild/meson

Issue:
string: Add missing FeatureNew tags to methods
There are some new(er) methods that have not version reference, so add
the missing ones in order to be properly notified when targetting older
meson versions.


Discussion:

Resolving patch:
diff --git a/mesonbuild/interpreter/primitives/string.py b/mesonbuild/interpreter/primitives/string.py
--- a/mesonbuild/interpreter/primitives/string.py
+++ b/mesonbuild/interpreter/primitives/string.py
@@ -117,6 +117,7 @@ def join_method(self, args: T.Tuple[T.List[str]], kwargs: TYPE_kwargs) -> str:
         return self.held_object.join(args[0])
 
     @noKwargs
+    @FeatureNew('str.replace', '0.58.0')
     @typed_pos_args('str.replace', str, str)
     def replace_method(self, args: T.Tuple[str, str], kwargs: TYPE_kwargs) -> str:
         return self.held_object.replace(args[0], args[1])
@@ -129,9 +130,12 @@ def split_method(self, args: T.Tuple[T.Optional[str]], kwargs: TYPE_kwargs) -> T
     @noKwargs
     @typed_pos_args('str.strip', optargs=[str])
     def strip_method(self, args: T.Tuple[T.Optional[str]], kwargs: TYPE_kwargs) -> str:
+        if args[0]:
+            FeatureNew.single_use('str.strip with a positional argument', '0.43.0', self.subproject, location=self.current_node)
         return self.held_object.strip(args[0])
 
     @noKwargs
+    @FeatureNew('str.substring', '0.56.0')
     @typed_pos_args('str.substring', optargs=[int, int])
     def substring_method(self, args: T.Tuple[T.Optional[int], T.Optional[int]], kwargs: TYPE_kwargs) -> str:
         start = args[0] if args[0] is not None else 0


Test patch:
Repository: mesonbuild/meson

Issue:
--host is set wrongly for external_project
**Describe the bug**
If you do this:
```
p = mod.add_project('configure',
  configure_options : [
    '--prefix=@PREFIX@'
  ],
  verbose: true
)
```
then in cross-compilation mode you'll
get configure error:
```
checking build system type... x86_64-pc-linux-gnu
checking host system type... Invalid configuration `x86-linux-linux': OS `linux' not recognized
```

The correct value is `x86-pc-linux` rather
than `x86-linux-linux`.
The problem happens somewhere in
`external_project.py:140`.
It shouldn't be using `self.build_machine.system`
here perhaps.


Discussion:

Resolving patch:
diff --git a/mesonbuild/modules/external_project.py b/mesonbuild/modules/external_project.py
--- a/mesonbuild/modules/external_project.py
+++ b/mesonbuild/modules/external_project.py
@@ -136,8 +136,9 @@ def _configure(self, state: 'ModuleState') -> None:
         configure_cmd += self._format_options(self.configure_options, d)
 
         if self.env.is_cross_build():
-            host = '{}-{}-{}'.format(self.host_machine.cpu_family,
-                                     self.build_machine.system,
+            host = '{}-{}-{}'.format(self.host_machine.cpu,
+                                     'pc' if self.host_machine.cpu_family in {"x86", "x86_64"}
+                                     else 'unknown',
                                      self.host_machine.system)
             d = [('HOST', None, host)]
             configure_cmd += self._format_options(self.cross_configure_options, d)


Test patch:
Repository: mesonbuild/meson

Issue:
Setting `b_vscrt` via `meson setup --reconfigure` has no effect on the generated `build.ninja`
Reconfiguring with a different value of `b_vscrt` does not result in changes to `build.ninja`.

Running `meson setup` with `-Db_vscrt=mdd` results in the correct flag being passed to the compiler:
```
$ meson setup build --vsenv -Db_vscrt=mdd
...
  User defined options
    vsenv        : True
    b_vscrt      : mdd
...
$ grep '/MD' build/build.ninja
 ARGS = ... "/MDd" "/nologo" "/showIncludes" "/utf-8" "/W2" "/std:c11" "/O2" "/Zi" ...
...
```
edited to remove unrelated output. However, reconfiguring with `-Db_vscrt=md` has no effect:
```
$ meson setup build --vsenv -Db_vscrt=md --reconfigure
...
  User defined options
    vsenv        : True
    b_vscrt      : md
...
$ grep '/MD' build/build.ninja
 ARGS = ... "/MDd" "/nologo" "/showIncludes" "/utf-8" "/W2" "/std:c11" "/O2" "/Zi" ...
...
```
also edited to remove unrelated output. I would have expected the `/MDd` flag to be turned into `/MD`.

This is Windows with VS 17.5.3, Python 3.10, meson 1.1.0 and ninja 1.10.2.



Discussion:
This seems to be true for all base options. For instance, `b_ndebug` faces the same problem.

Resolving patch:
diff --git a/mesonbuild/coredata.py b/mesonbuild/coredata.py
--- a/mesonbuild/coredata.py
+++ b/mesonbuild/coredata.py
@@ -985,9 +985,11 @@ def set_default_options(self, default_options: T.MutableMapping[OptionKey, str],
             # not differ between them even when they are valid for both.
             if subproject and k.is_builtin() and self.options[k.evolve(subproject='', machine=MachineChoice.HOST)].yielding:
                 continue
-            # Skip base, compiler, and backend options, they are handled when
+            # Skip compiler and backend options, they are handled when
             # adding languages and setting backend.
-            if k.type in {OptionType.COMPILER, OptionType.BACKEND, OptionType.BASE}:
+            if k.type in {OptionType.COMPILER, OptionType.BACKEND}:
+                continue
+            if k.type == OptionType.BASE and env.first_invocation:
                 continue
             options[k] = v
 


Test patch: