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

Issue:
WARNING: Unknown CPU family 'm68k'
I just ran the build of ```libpeas``` on Debian unstable (m68k) and received the following warning message:

```WARNING: Unknown CPU family 'm68k', please report this at https://github.com/mesonbuild/meson/issues/new with the output of `uname -a` and `cat /proc/cpuinfo` ```

Here's the output of ```cat /proc/cpuinfo``` on my Amiga 4000 (68060):

```
root@elgar:~> cat /proc/cpuinfo
CPU:            68060
MMU:            68060
FPU:            68060
Clocking:       49.1MHz
BogoMips:       98.20
Calibration:    491008 loops
root@elgar:~>
```

And here on ```qemu-m68k-system```:

```
root@pacman:~# cat /proc/cpuinfo 
CPU:            68040
MMU:            68040
FPU:            68040
Clocking:       2381.4MHz
BogoMips:       1587.60
Calibration:    7938048 loops
root@pacman:~#
```

Build log available in: https://buildd.debian.org/status/fetch.php?pkg=libpeas&arch=m68k&ver=1.24.1-2&stamp=1579603436&raw=0


Discussion:

Resolving patch:
diff --git a/mesonbuild/envconfig.py b/mesonbuild/envconfig.py
--- a/mesonbuild/envconfig.py
+++ b/mesonbuild/envconfig.py
@@ -42,6 +42,7 @@
     'arm',
     'e2k',
     'ia64',
+    'm68k',
     'microblaze',
     'mips',
     'mips64',


Test patch:
Repository: mesonbuild/meson

Issue:
Add warnings when environment variables change and wont be honored
We only honor most environment variables in `meson setup`, and not in `meson configure` or ninja, with #4931 that extends to pkg-config as well. We really should have a warning when we detect that those environment variables have changed and wont be honored, at least for `meson configure`.


Discussion:

Resolving patch:
diff --git a/mesonbuild/coredata.py b/mesonbuild/coredata.py
--- a/mesonbuild/coredata.py
+++ b/mesonbuild/coredata.py
@@ -19,7 +19,7 @@
 from pathlib import PurePath
 from collections import OrderedDict
 from .mesonlib import (
-    MesonException, MachineChoice, PerMachine,
+    MesonException, MachineChoice, PerMachine, OrderedSet,
     default_libdir, default_libexecdir, default_prefix, split_args
 )
 from .wrap import WrapMode
@@ -746,16 +746,20 @@ def set_default_options(self, default_options, subproject, env):
         # Some options default to environment variables if they are
         # unset, set those now. These will either be overwritten
         # below, or they won't. These should only be set on the first run.
-        if env.first_invocation:
-            p_env = os.environ.get('PKG_CONFIG_PATH')
-            if p_env:
-                # PKG_CONFIG_PATH may contain duplicates, which must be
-                # removed, else a duplicates-in-array-option warning arises.
-                pkg_config_paths = []
-                for k in p_env.split(':'):
-                    if k not in pkg_config_paths:
-                        pkg_config_paths.append(k)
-                options['pkg_config_path'] = pkg_config_paths
+        p_env = os.environ.get('PKG_CONFIG_PATH')
+        if p_env:
+            # PKG_CONFIG_PATH may contain duplicates, which must be
+            # removed, else a duplicates-in-array-option warning arises.
+            p_list = list(OrderedSet(p_env.split(':')))
+            if env.first_invocation:
+                options['pkg_config_path'] = p_list
+            elif options.get('pkg_config_path', []) != p_list:
+                mlog.warning(
+                    'PKG_CONFIG_PATH environment variable has changed '
+                    'between configurations, meson ignores this. '
+                    'Use -Dpkg_config_path to change pkg-config search '
+                    'path instead.'
+                )
 
         for k, v in env.cmd_line_options.items():
             if subproject:
@@ -1074,8 +1078,8 @@ def add_to_argparse(self, name: str, parser: argparse.ArgumentParser, prefix: st
 ])
 
 builtin_options_per_machine = OrderedDict([
-    ('pkg_config_path', BuiltinOption(UserArrayOption, 'T.List of additional paths for pkg-config to search', [])),
-    ('cmake_prefix_path', BuiltinOption(UserArrayOption, 'T.List of additional prefixes for cmake to search', [])),
+    ('pkg_config_path', BuiltinOption(UserArrayOption, 'List of additional paths for pkg-config to search', [])),
+    ('cmake_prefix_path', BuiltinOption(UserArrayOption, 'List of additional prefixes for cmake to search', [])),
 ])
 
 # Special prefix-dependent defaults for installation directories that reside in


Test patch:
Repository: mesonbuild/meson

Issue:
ICL detection is too trivial
It seems the presence of the string "icl" anywhere in the compiler name is enough to qualify as the ICL compiler. Consequently using a compiler named e.g. "arm-particle-linux-gnueabi-gcc" is not possible.

```
meson.build:21:0: ERROR: Unknown compiler(s): [['arm-particle-linux-gnueabi-gcc', '-mthumb', '-mfpu=neon-vfpv4', '-mfloat-abi=hard', '-mcpu=cortex-a7', '-fstack-protector-strong', '-D_FORTIFY_SOURCE=2', '-Wformat', '-Wformat-security', '-Werror=format-security', '--sysroot=/home/christian/embedded/yocto/raspi/build/tmp/work/cortexa7t2hf-neon-vfpv4-particle-linux-gnueabi/libdrm/2.4.99-r0/recipe-sysroot']]
```

A compiler named e.g. "arm-partile-linux-gnueabi-gcc" works as expected.

Meson version: 0.51.2


Discussion:

Resolving patch:
diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
--- a/mesonbuild/environment.py
+++ b/mesonbuild/environment.py
@@ -909,7 +909,7 @@ def sanitize(p):
                 arg = '--vsn'
             elif 'ccrx' in compiler_name:
                 arg = '-v'
-            elif 'icl' in compiler_name:
+            elif compiler_name in {'icl', 'icl.exe'}:
                 # if you pass anything to icl you get stuck in a pager
                 arg = ''
             else:


Test patch:
Repository: mesonbuild/meson

Issue:
.hgtags included in dist archive
**Describe the bug**

When running `ninja dist` the resulting `tar.xz` includes the `.hgtags` files that distros (namely debian) will mark as a packaging error.

**To Reproduce**

Run `ninja dist` on a mercurial repository that has at least 1 tag.

**Expected behavior**
That the archive does not have the `.hgtags` file in it.  I just did an `hg archive` and unfortunately saw that `.hgtags` was there as well.

**system parameters**
* Is this a [cross build](https://mesonbuild.com/Cross-compilation.html) or just a plain native build (for the same computer)? Native
* what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.) Linux, Debian Unstable
* what Python version are you using e.g. 3.8.0: 3.7.6
* what `meson --version`: 0.53.1
* what `ninja --version` if it's a Ninja build: 1.9.0



Discussion:
Did a little bit more digging and it looks like `-X .hgtags` can be passed along to `hg archive` and it'll skip that file.

Resolving patch:
diff --git a/mesonbuild/mdist.py b/mesonbuild/mdist.py
--- a/mesonbuild/mdist.py
+++ b/mesonbuild/mdist.py
@@ -151,7 +151,16 @@ def create_dist_hg(dist_name, archives, src_root, bld_root, dist_sub, dist_scrip
     xzname = tarname + '.xz'
     gzname = tarname + '.gz'
     zipname = os.path.join(dist_sub, dist_name + '.zip')
-    subprocess.check_call(['hg', 'archive', '-R', src_root, '-S', '-t', 'tar', tarname])
+    # Note that -X interprets relative paths using the current working
+    # directory, not the repository root, so this must be an absolute path:
+    # https://bz.mercurial-scm.org/show_bug.cgi?id=6267
+    #
+    # .hg[a-z]* is used instead of .hg* to keep .hg_archival.txt, which may
+    # be useful to link the tarball to the Mercurial revision for either
+    # manual inspection or in case any code interprets it for a --version or
+    # similar.
+    subprocess.check_call(['hg', 'archive', '-R', src_root, '-S', '-t', 'tar',
+                           '-X', src_root + '/.hg[a-z]*', tarname])
     output_names = []
     if 'xztar' in archives:
         import lzma


Test patch:
Repository: mesonbuild/meson

Issue:
unknown cpu family 'mips64el'
Sent here by a configure message on OpenBSD running on a loongson.

$ uname -a
OpenBSD hackbookpro.attlocal.net 6.6 GENERIC#18 loongson
$ machine -a
mips64el


Discussion:

Resolving patch:
diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
--- a/mesonbuild/environment.py
+++ b/mesonbuild/environment.py
@@ -338,6 +338,8 @@ def detect_cpu_family(compilers: CompilersDict) -> str:
         trial = 'x86_64'
     elif trial in {'sun4u', 'sun4v'}:
         trial = 'sparc64'
+    elif trial in {'mipsel', 'mips64el'}:
+        trial = trial.rstrip('el')
 
     # On Linux (and maybe others) there can be any mixture of 32/64 bit code in
     # the kernel, Python, system, 32-bit chroot on 64-bit host, etc. The only
@@ -369,6 +371,7 @@ def detect_cpu(compilers: CompilersDict):
         trial = platform.processor().lower()
     else:
         trial = platform.machine().lower()
+
     if trial in ('amd64', 'x64', 'i86pc'):
         trial = 'x86_64'
     if trial == 'x86_64':
@@ -384,6 +387,9 @@ def detect_cpu(compilers: CompilersDict):
     elif trial == 'e2k':
         # Make more precise CPU detection for Elbrus platform.
         trial = platform.processor().lower()
+    elif trial.startswith('mips'):
+        trial = trial.rstrip('el')
+
     # Add more quirks here as bugs are reported. Keep in sync with
     # detect_cpu_family() above.
     return trial


Test patch:
Repository: mesonbuild/meson

Issue:
Unable to cross build glib

[my-meson-cross-file.txt](https://github.com/mesonbuild/meson/files/4275963/my-meson-cross-file.txt)
**Describe the bug**
The configure step fails during the configuration of glib:

```
  File "/home/scerveau/DEV/EXTERNAL/meson/mesonbuild/modules/pkgconfig.py", line 71, in _check_generated_pc_deprecation
    location=obj.generated_pc_warn[1])
  File "/home/scerveau/DEV/EXTERNAL/meson/mesonbuild/mlog.py", line 279, in deprecation
    return _log_error('deprecation', *args, **kwargs, is_error=True)
  File "/home/scerveau/DEV/EXTERNAL/meson/mesonbuild/mlog.py", line 253, in _log_error
    if location is not None:
AttributeError: 'types.SimpleNamespace' object has no attribute 'filename'
```

**To Reproduce**
Checkout gst-build and try to cross build with the given cross-file attached
[my-meson-cross-file.txt](https://github.com/mesonbuild/meson/files/4275967/my-meson-cross-file.txt)


**Expected behavior**

To finish the configuration step without failing

**system parameters**
* Is this a [cross build](https://mesonbuild.com/Cross-compilation.html) or just a plain native build (for the same computer)? yes
* what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.)

Ubuntu 18.04

* what Python version are you using e.g. 3.8.0
3.6.9
* what `meson --version`
master b190a20a
* what `ninja --version` if it's a Ninja build
1.8.2


Discussion:

Resolving patch:
diff --git a/mesonbuild/modules/pkgconfig.py b/mesonbuild/modules/pkgconfig.py
--- a/mesonbuild/modules/pkgconfig.py
+++ b/mesonbuild/modules/pkgconfig.py
@@ -526,8 +526,7 @@ def parse_variable_list(stringlist):
             for lib in deps.pub_libs:
                 if not isinstance(lib, str) and not hasattr(lib, 'generated_pc'):
                     lib.generated_pc = filebase
-                    location = types.SimpleNamespace(subdir=state.subdir,
-                                                     lineno=state.current_lineno)
+                    location = state.current_node
                     lib.generated_pc_warn = [name, location]
         return ModuleReturnValue(res, [res])
 


Test patch:
Repository: mesonbuild/meson

Issue:
meson will fail when use the Chinese version of VS2017
**Describe the bug**
1. install  VS2017 with zh_cn
2. make a meson.build 
3.  exec  meson  build . when will show:
        meson.build:1:0: ERROR: Failed to detect MSVC compiler target architecture: 'cl /?' output is
���� x64 �� Microsoft (R) C/C++ �Ż������� 19.16.27035 ��

**To Reproduce**
" cl /?"  output :   
用于 x64 的 Microsoft (R) C/C++ 优化编译器 19.16.27035 版

there is a bug  in environment.py:

                cl_signature = lookat.split('\n')[0]
                match = re.search('.*(x86|x64|ARM|ARM64)$', cl_signature)
       
  This expression may fail in a non-english version.

**Expected behavior**
 match = re.search('.*(x86|x64|ARM|ARM64)', cl_signature)

**system parameters**




Discussion:

Resolving patch:
diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
--- a/mesonbuild/environment.py
+++ b/mesonbuild/environment.py
@@ -1063,7 +1063,7 @@ def sanitize(p):
                     m = 'Failed to detect MSVC compiler version: stderr was\n{!r}'
                     raise EnvironmentException(m.format(err))
                 cl_signature = lookat.split('\n')[0]
-                match = re.search('.*(x86|x64|ARM|ARM64)$', cl_signature)
+                match = re.search('.*(x86|x64|ARM|ARM64)( |$)', cl_signature)
                 if match:
                     target = match.group(1)
                 else:


Test patch:
Repository: mesonbuild/meson

Issue:
TypeError when setting up a build directory with LLVM linker
**Describe the bug**
https://gist.github.com/Akaricchi/23cde7c6782a150af568db920f17a5af

**To Reproduce**
Try to set up a build directory with the [llvm-mingw](https://github.com/mstorsjo/llvm-mingw) cross toolchain. Not sure if native compilation is affected.

**Expected behavior**
Successful generation of the build directory.

**system parameters**
* Cross build (windows i686 via llvm-mingw)
* openSUSE Tumbleweed
* Python 3.8.2
* meson 0.53.999 (b54e557a40497a0f9080e32cd0da91b2b59762cc)
* ninja 1.10.0



Discussion:
On further inspection, this is actually not related to `--wipe`. This error happens even when setting up a fresh build directory using the LLVM linker.

Resolving patch:
diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
--- a/mesonbuild/environment.py
+++ b/mesonbuild/environment.py
@@ -780,7 +780,7 @@ def _guess_win_linker(self, compiler: T.List[str], comp_class: Compiler,
             if '(compatible with GNU linkers)' in o:
                 return LLVMDynamicLinker(
                     compiler, for_machine, comp_class.LINKER_PREFIX,
-                    override, version=search_version(o), direct=invoked_directly)
+                    override, version=search_version(o))
  
         if value is not None and invoked_directly:
             compiler = value


Test patch:
Repository: mesonbuild/meson

Issue:
restorecon called with empty input
**Describe the bug**
If there is nothing to install, `ninja install` shows a slightly misleading restorecon error 

**To Reproduce**
Basically empty `meson.build`
```
project('empty')
```
and then:
```
meson build
cd build
ninja install
```
yields:
```
[0/1] Installing files.
Failed to restore SELinux context of installed files...
Standard output:

Standard error:
restorecon: SELinux: Could not get canonical path for  restorecon: No such file or directory.

Nothing to install.
```

**Expected behavior**
No error message.

**System parameters**
Seen with the Fedora 31 Meson package (meson-0.52.1-1.fc31.noarch).

**Note**
Note the extra space before restorecon in the message. What happens is that restorecon is called with an empty input in `restore_selinux_contexts()`
```
out, err = proc.communicate(input=b'\0'.join(os.fsencode(f) for f in selinux_updates) + b'\0')
```
telling it to process a file with name '', where it shouldn't be called at all, because `selinux_updates` is empty. Should be easily fixable with a `if not selinux_updates: return`.


Discussion:

Resolving patch:
diff --git a/mesonbuild/minstall.py b/mesonbuild/minstall.py
--- a/mesonbuild/minstall.py
+++ b/mesonbuild/minstall.py
@@ -171,6 +171,10 @@ def restore_selinux_contexts():
         # If we don't have restorecon, failure is ignored quietly.
         return
 
+    if not selinux_updates:
+        # If the list of files is empty, do not try to call restorecon.
+        return
+
     with subprocess.Popen(['restorecon', '-F', '-f-', '-0'],
                           stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE) as proc:
         out, err = proc.communicate(input=b'\0'.join(os.fsencode(f) for f in selinux_updates) + b'\0')


Test patch:
Repository: mesonbuild/meson

Issue:
0.54 test suite does not pass
0.54 introduces new test suite failures.

After fixing #6868, the `test_templates` still does not pass because of cuda:

```
Using "tmpqayyrpfm" (name of current directory) as project name.
Using "tmpqayyrpfm" (project name) as name of executable to build.
Sample project created. To build it run the
following commands:

meson builddir
ninja -C builddir


The Meson build system
Version: 0.54.0
Source dir: /tmp/tmpqayyrpfm
Build dir: /tmp/tmpqayyrpfm/builddir
Build type: native build
Project name: tmpqayyrpfm
Project version: 0.1
C++ compiler for the host machine: c++ (gcc 9.3.0 "c++ (Arch Linux 9.3.0-1) 9.3.0")
C++ linker for the host machine: c++ ld.bfd 2.34
Host machine cpu family: x86_64
Host machine cpu: x86_64

meson.build:6:0: ERROR: No host machine compiler for "tmpqayyrpfm.cu"
```

The latter cuda test cases succeed, though.

```
Succeeded test: test cases/cuda/1 simple
Succeeded test: test cases/cuda/2 split
Succeeded test: test cases/cuda/3 cudamodule
Succeeded test: test cases/cuda/4 shared
Succeeded test: test cases/cuda/5 threads
Succeeded test: test cases/cuda/6 std
Succeeded test: test cases/cuda/7 static vs runtime
Succeeded test: test cases/cuda/8 release
Succeeded test: test cases/cuda/9 optimize for space
Succeeded test: test cases/cuda/10 cuda dependency
Succeeded test: test cases/cuda/11 cuda dependency (nvcc)
Succeeded test: test cases/cuda/12 cuda dependency (mixed)
```


Discussion:

Resolving patch:
diff --git a/mesonbuild/templates/cudatemplates.py b/mesonbuild/templates/cudatemplates.py
--- a/mesonbuild/templates/cudatemplates.py
+++ b/mesonbuild/templates/cudatemplates.py
@@ -29,7 +29,7 @@
 }}
 '''
 
-hello_cuda_meson_template = '''project('{project_name}', 'cpp',
+hello_cuda_meson_template = '''project('{project_name}', ['cuda', 'cpp'],
   version : '{version}',
   default_options : ['warning_level=3',
                      'cpp_std=c++14'])
@@ -101,7 +101,7 @@ class {utoken}_PUBLIC {class_name} {{
 }}
 '''
 
-lib_cuda_meson_template = '''project('{project_name}', 'cuda',
+lib_cuda_meson_template = '''project('{project_name}', ['cuda', 'cpp'],
   version : '{version}',
   default_options : ['warning_level=3'])
 


Test patch:
Repository: mesonbuild/meson

Issue:
--backend=vs2019 EntryPointSymbol incorrect for 'UNICODE' projects
**Describe the bug**
vcxproj files generated by meson have an incorrect EntryPointSymbol for UNICODE applications (ie. those that have an entry point of wmain (console) or wWinMain (gui)).

```
2>MSVCRTD.lib(exe_main.obj) : error LNK2019: unresolved external symbol main referenced in function "int __cdecl invoke_main(void)" (?invoke_main@@YAHXZ)
2>.\main.exe : fatal error LNK1120: 1 unresolved externals
```

Removing EntryPointSymbol from all generated .vcxproj files works around the issue.

Ninja builds do not have this issue.

**To Reproduce**
meson.build:
``` meson
project('wmain', 'c')

executable('main', 'wmain.c')
```
wmain.c:
``` c
#include <stdio.h>

int wmain(int argc, wchar_t *argv[]) {
    printf("Hello, World!\n");
}
```

**Expected behavior**
main.exe should be generated instead of a link error.

**system parameters**
This is a native build, with Visual Studio 2019, on Windows 10, with meson and ninja from the official 0.53.1 MSI (I looked at the code, and it's still the same in master on github).



Discussion:

Resolving patch:
diff --git a/mesonbuild/backend/vs2010backend.py b/mesonbuild/backend/vs2010backend.py
--- a/mesonbuild/backend/vs2010backend.py
+++ b/mesonbuild/backend/vs2010backend.py
@@ -744,19 +744,16 @@ def _prettyprint_vcxproj_xml(self, tree, ofname):
 
     def gen_vcxproj(self, target, ofname, guid):
         mlog.debug('Generating vcxproj %s.' % target.name)
-        entrypoint = 'WinMainCRTStartup'
         subsystem = 'Windows'
         self.handled_target_deps[target.get_id()] = []
         if isinstance(target, build.Executable):
             conftype = 'Application'
             if not target.gui_app:
                 subsystem = 'Console'
-                entrypoint = 'mainCRTStartup'
         elif isinstance(target, build.StaticLibrary):
             conftype = 'StaticLibrary'
         elif isinstance(target, build.SharedLibrary):
             conftype = 'DynamicLibrary'
-            entrypoint = '_DllMainCrtStartup'
         elif isinstance(target, build.CustomTarget):
             return self.gen_custom_target_vcxproj(target, ofname, guid)
         elif isinstance(target, build.RunTarget):
@@ -1180,8 +1177,6 @@ def gen_vcxproj(self, target, ofname, guid):
         if '/ZI' in buildtype_args or '/Zi' in buildtype_args:
             pdb = ET.SubElement(link, 'ProgramDataBaseFileName')
             pdb.text = '$(OutDir}%s.pdb' % target_name
-        if isinstance(target, build.Executable):
-            ET.SubElement(link, 'EntryPointSymbol').text = entrypoint
         targetmachine = ET.SubElement(link, 'TargetMachine')
         targetplatform = self.platform.lower()
         if targetplatform == 'win32':


Test patch:
Repository: mesonbuild/meson

Issue:
--backend=vs2019 DebugInformationFormat is not set correctly
**Describe the bug**
DebugInformationFormat is set in the Configuration PropertyGroup, but Visual Studio 2019 only reads it from the ClCompile section.

It looks like vs2010backend.py accidentally sets DebugInformationFormat=EditAndContinue in type_config instead of clconf. (Possibly BasicRuntimeChecks too). It's possible that older Visual Studio wants this value outside ClCompile. I didn't check, but it seems unlikely.

**To Reproduce**
meson --backend=vs2019 --buildtype=debug <any source dir>

**Expected behavior**
Projects built with the default debug configuration in visual studio (not from ninja) should be built with /ZI (Program Database for Edit and Continue).


Discussion:

Resolving patch:
diff --git a/mesonbuild/backend/vs2010backend.py b/mesonbuild/backend/vs2010backend.py
--- a/mesonbuild/backend/vs2010backend.py
+++ b/mesonbuild/backend/vs2010backend.py
@@ -844,18 +844,18 @@ def gen_vcxproj(self, target, ofname, guid):
             ET.SubElement(clconf, 'RuntimeLibrary').text = 'MultiThreadedDLL'
         # Debug format
         if '/ZI' in buildtype_args:
-            ET.SubElement(type_config, 'DebugInformationFormat').text = 'EditAndContinue'
+            ET.SubElement(clconf, 'DebugInformationFormat').text = 'EditAndContinue'
         elif '/Zi' in buildtype_args:
-            ET.SubElement(type_config, 'DebugInformationFormat').text = 'ProgramDatabase'
+            ET.SubElement(clconf, 'DebugInformationFormat').text = 'ProgramDatabase'
         elif '/Z7' in buildtype_args:
-            ET.SubElement(type_config, 'DebugInformationFormat').text = 'OldStyle'
+            ET.SubElement(clconf, 'DebugInformationFormat').text = 'OldStyle'
         # Runtime checks
         if '/RTC1' in buildtype_args:
-            ET.SubElement(type_config, 'BasicRuntimeChecks').text = 'EnableFastChecks'
+            ET.SubElement(clconf, 'BasicRuntimeChecks').text = 'EnableFastChecks'
         elif '/RTCu' in buildtype_args:
-            ET.SubElement(type_config, 'BasicRuntimeChecks').text = 'UninitializedLocalUsageCheck'
+            ET.SubElement(clconf, 'BasicRuntimeChecks').text = 'UninitializedLocalUsageCheck'
         elif '/RTCs' in buildtype_args:
-            ET.SubElement(type_config, 'BasicRuntimeChecks').text = 'StackFrameRuntimeCheck'
+            ET.SubElement(clconf, 'BasicRuntimeChecks').text = 'StackFrameRuntimeCheck'
         # End configuration
         ET.SubElement(root, 'Import', Project=r'$(VCTargetsPath)\Microsoft.Cpp.props')
         generated_files, custom_target_output_files, generated_files_include_dirs = self.generate_custom_generator_commands(target, root)


Test patch: