Repository: mesonbuild/meson

Issue:
mingw: has_function() MSYS2 workaround no longer works with gcc 10
**Describe the bug**

has_function for stpcpy and posix_memalign now return true on Windows with gcc 10

My guess is that this is because the workaround here:

https://github.com/mesonbuild/meson/blob/39ca178d21a72a8f7560b657b517fb73f81b4a89/mesonbuild/compilers/mixins/clike.py#L738

no longer works because gcc 10 now supports __has_builtin.

**To Reproduce**

```meson
project('glib', 'c', 'cpp',
  version : '2.65.0',
)

cc = meson.get_compiler('c')
cc.has_function('posix_memalign', prefix : '#include <stdlib.h>')
```

```meson
The Meson build system
Version: 0.54.1
Source dir: C:/msys64/home/user/foo
Build dir: C:/msys64/home/user/foo/_build
Build type: native build
Using 'PKG_CONFIG_PATH' from environment with value: 'C:\\msys64\\mingw64\\lib\\pkgconfig;C:\\msys64\\mingw64\\share\\pkgconfig'
Using 'PKG_CONFIG_PATH' from environment with value: 'C:\\msys64\\mingw64\\lib\\pkgconfig;C:\\msys64\\mingw64\\share\\pkgconfig'
Project name: glib
Project version: 2.65.0
C compiler for the host machine: ccache cc (gcc 10.1.0 "cc (Rev1, Built by MSYS2 project) 10.1.0")
C linker for the host machine: cc ld.bfd 2.34
C++ compiler for the host machine: ccache c++ (gcc 10.1.0 "c++ (Rev1, Built by MSYS2 project) 10.1.0")
C++ linker for the host machine: c++ ld.bfd 2.34
Host machine cpu family: x86_64
Host machine cpu: x86_64
Checking for function "posix_memalign" : YES
Build targets in project: 0

Found ninja.EXE-1.10.0 at C:\msys64\mingw64\bin/ninja.EXE
```

**Expected behavior**

```meson
Checking for function "posix_memalign" : NO
```



Discussion:

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
@@ -727,24 +727,29 @@ def has_function(self, funcname, prefix, env, *, extra_args=None, dependencies=N
         # need to look for them differently. On nice compilers like clang, we
         # can just directly use the __has_builtin() macro.
         fargs['no_includes'] = '#include' not in prefix
-        fargs['__builtin_'] = '' if funcname.startswith('__builtin_') else '__builtin_'
+        is_builtin = funcname.startswith('__builtin_')
+        fargs['is_builtin'] = is_builtin
+        fargs['__builtin_'] = '' if is_builtin else '__builtin_'
         t = '''{prefix}
         int main(void) {{
+
+        /* With some toolchains (MSYS2/mingw for example) the compiler
+         * provides various builtins which are not really implemented and
+         * fall back to the stdlib where they aren't provided and fail at
+         * build/link time. In case the user provides a header, including
+         * the header didn't lead to the function being defined, and the
+         * function we are checking isn't a builtin itself we assume the
+         * builtin is not functional and we just error out. */
+        #if !{no_includes:d} && !defined({func}) && !{is_builtin:d}
+            #error "No definition for {__builtin_}{func} found in the prefix"
+        #endif
+
         #ifdef __has_builtin
             #if !__has_builtin({__builtin_}{func})
                 #error "{__builtin_}{func} not found"
             #endif
         #elif ! defined({func})
-            /* Check for {__builtin_}{func} only if no includes were added to the
-             * prefix above, which means no definition of {func} can be found.
-             * We would always check for this, but we get false positives on
-             * MSYS2 if we do. Their toolchain is broken, but we can at least
-             * give them a workaround. */
-            #if {no_includes:d}
-                {__builtin_}{func};
-            #else
-                #error "No definition for {__builtin_}{func} found in the prefix"
-            #endif
+            {__builtin_}{func};
         #endif
         return 0;
         }}'''


Test patch: