Bug 252892

Summary: clang 11.0.0: fails to build devel/onetbb
Product: Base System Reporter: Thierry Thomas <thierry>
Component: binAssignee: Ganael LAPLANCHE <martymac>
Status: Closed FIXED    
Severity: Affects Only Me CC: brooks, dim, martymac
Priority: --- Flags: dim: mfc-stable13+
dim: mfc-stable12+
dim: mfc-stable11+
Version: CURRENT   
Hardware: amd64   
OS: Any   
Bug Depends on:    
Bug Blocks: 252648    
Attachments:
Description Flags
Diagnostic .cpp file (gzipped)
none
Diagnostic .sh file (gzipped) none

Description Thierry Thomas freebsd_committer 2021-01-21 17:25:00 UTC
Trying to build devel/onetbb from the shar file included in PR 252648, clang fails.

See details already reported in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252648#c13

The requested files are also attached to the same PR:
- https://bugs.freebsd.org/bugzilla/attachment.cgi?id=221792
- https://bugs.freebsd.org/bugzilla/attachment.cgi?id=221793
Comment 1 Ganael LAPLANCHE freebsd_committer 2021-01-21 17:44:04 UTC
Thans for the report. I'll have a look at that!
Comment 2 Ganael LAPLANCHE freebsd_committer 2021-01-22 11:34:51 UTC
Hello Thierry,

I could not reproduce the problem on 12.2-RELEASE using clang11 explicitly.

I.e. with the following patch to Makefile:

+# XXX Test
+BUILD_DEPENDS+=        ${LOCALBASE}/bin/clang11:devel/llvm11
+CPP=   ${LOCALBASE}/bin/clang-cpp11
+CC=        ${LOCALBASE}/bin/clang11
+CXX=   ${LOCALBASE}/bin/clang++11

See:

http://box.martymac.org/FreeBSD-Packages/data/FBSD122amd64-tbb-migr/2021-01-21_18h55m30s/logs/onetbb-2021.1.1.log

Could that be related to -CURRENT itself ?

Any hint ?
Comment 3 Ganael LAPLANCHE freebsd_committer 2021-01-24 16:57:47 UTC
I'll set up a 13-STABLE and see if I can reproduce the problem, stay tuned.
Comment 4 Ganael LAPLANCHE freebsd_committer 2021-01-25 18:11:00 UTC
I could reproduce the problem on 14-CURRENT with llvm11. Weird, I could not reproduce it on 12.2 with llvm11 from ports.

Here are the logs I get :

# /usr/bin/c++ -v -I/usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test/.. -I/usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test -I/usr/ports/devel/onetbb/work/oneTBB-2021.1.1/src/tbb/../../include -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -Wall -Wextra -Wshadow -Wcast-qual -Woverloaded-virtual -Wnon-virtual-dtor -Wno-parentheses -pthread -std=c++11 -MD -MT test/CMakeFiles/conformance_blocked_rangeNd.dir/conformance/conformance_blocked_rangeNd.cpp.o -MF test/CMakeFiles/conformance_blocked_rangeNd.dir/conformance/conformance_blocked_rangeNd.cpp.o.d -o test/CMakeFiles/conformance_blocked_rangeNd.dir/conformance/conformance_blocked_rangeNd.cpp.o -c /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test/conformance/conformance_blocked_rangeNd.cpp 
FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)
Target: x86_64-unknown-freebsd14.0
Thread model: posix
InstalledDir: /usr/bin
 (in-process)
 "/usr/bin/c++" -cc1 -triple x86_64-unknown-freebsd14.0 -emit-obj -disable-free -main-file-name conformance_blocked_rangeNd.cpp -mrelocation-model static -mframe-pointer=all -relaxed-aliasing -fno-rounding-math -mconstructor-aliases -munwind-tables -target-cpu x86-64 -fno-split-dwarf-inlining -debugger-tuning=gdb -v -resource-dir /usr/lib/clang/11.0.1 -dependency-file test/CMakeFiles/conformance_blocked_rangeNd.dir/conformance/conformance_blocked_rangeNd.cpp.o.d -MT test/CMakeFiles/conformance_blocked_rangeNd.dir/conformance/conformance_blocked_rangeNd.cpp.o -sys-header-deps -I /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test/.. -I /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test -I /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/src/tbb/../../include -internal-isystem /usr/include/c++/v1 -O2 -Wall -Wextra -Wshadow -Wcast-qual -Woverloaded-virtual -Wnon-virtual-dtor -Wno-parentheses -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /usr/ports/devel/onetbb/work/.build -ferror-limit 19 -pthread -stack-protector 2 -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fcolor-diagnostics -vectorize-loops -vectorize-slp -faddrsig -o test/CMakeFiles/conformance_blocked_rangeNd.dir/conformance/conformance_blocked_rangeNd.cpp.o -x c++ /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test/conformance/conformance_blocked_rangeNd.cpp
clang -cc1 version 11.0.1 based upon LLVM 11.0.1 default target x86_64-unknown-freebsd14.0
#include "..." search starts here:
#include <...> search starts here:
 /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test/..
 /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test
 /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/src/tbb/../../include
 /usr/include/c++/v1
 /usr/lib/clang/11.0.1/include
 /usr/include
End of search list.
Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"), function cast, file /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Casting.h, line 269.
PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: /usr/bin/c++ -v -I/usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test/.. -I/usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test -I/usr/ports/devel/onetbb/work/oneTBB-2021.1.1/src/tbb/../../include -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -Wall -Wextra -Wshadow -Wcast-qual -Woverloaded-virtual -Wnon-virtual-dtor -Wno-parentheses -pthread -std=c++11 -MD -MT test/CMakeFiles/conformance_blocked_rangeNd.dir/conformance/conformance_blocked_rangeNd.cpp.o -MF test/CMakeFiles/conformance_blocked_rangeNd.dir/conformance/conformance_blocked_rangeNd.cpp.o.d -o test/CMakeFiles/conformance_blocked_rangeNd.dir/conformance/conformance_blocked_rangeNd.cpp.o -c /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/test/conformance/conformance_blocked_rangeNd.cpp 
1.      /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/src/tbb/../../include/oneapi/tbb/blocked_rangeNd.h:69:62: current parser token ':'
2.      /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/src/tbb/../../include/oneapi/tbb/blocked_rangeNd.h:34:1: parsing namespace 'tbb'
3.      /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/src/tbb/../../include/oneapi/tbb/blocked_rangeNd.h:35:1: parsing namespace 'tbb::detail'
4.      /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/src/tbb/../../include/oneapi/tbb/blocked_rangeNd.h:36:1: parsing namespace 'tbb::detail::d1'
5.      /usr/ports/devel/onetbb/work/oneTBB-2021.1.1/src/tbb/../../include/oneapi/tbb/blocked_rangeNd.h:55:1: parsing struct/union/class body 'tbb::detail::d1::blocked_rangeNd_impl<Value, N, detail::index_sequence<Is...>>'
#0 0x00000000041d56fe PrintStackTrace /usr/src/contrib/llvm-project/llvm/lib/Support/Unix/Signals.inc:564:13
#1 0x00000000041d3955 RunSignalHandlers /usr/src/contrib/llvm-project/llvm/lib/Support/Signals.cpp:69:18
#2 0x0000000004172e3e HandleCrash /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:77:5
#3 0x0000000004172fc1 CrashRecoverySignalHandler /usr/src/contrib/llvm-project/llvm/lib/Support/CrashRecoveryContext.cpp:0:51
#4 0x0000000805692e00 handle_signal /usr/src/lib/libthr/thread/thr_sig.c:0:3
c++: error: clang frontend command failed due to signal (use -v to see invocation)
FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)
Target: x86_64-unknown-freebsd14.0
Thread model: posix
InstalledDir: /usr/bin
c++: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
c++: note: diagnostic msg: /tmp/conformance_blocked_rangeNd-d553c8.cpp
c++: note: diagnostic msg: /tmp/conformance_blocked_rangeNd-d553c8.sh
c++: note: diagnostic msg: 

********************
Comment 5 Ganael LAPLANCHE freebsd_committer 2021-01-25 18:14:28 UTC
Created attachment 221913 [details]
Diagnostic .cpp file (gzipped)
Comment 6 Ganael LAPLANCHE freebsd_committer 2021-01-25 18:14:50 UTC
Created attachment 221914 [details]
Diagnostic .sh file (gzipped)
Comment 7 Ganael LAPLANCHE freebsd_committer 2021-01-25 18:21:14 UTC
Hello,

Can someone from LLVM team have a look at that failure ?

Thanks in advance,

Ganael.
Comment 8 Ganael LAPLANCHE freebsd_committer 2021-01-25 18:24:15 UTC
Not sure if it is a bug of LLVM itself, but it seems so:

"c++: error: clang frontend command failed due to signal"

Any idea?
Comment 9 Dimitry Andric freebsd_committer 2021-01-25 18:36:28 UTC
On stable branches, and for LLVM ports, assertions are disabled so it will either continue happily (and maybe eat your data :), or it will encounter some other error like a segfault.

On -CURRENT (aka 'head' or 'main') we do have LLVM assertions enabled, so you will more easily run into them.

That said, I will have look at the reproduction files from bug 252892. Btw why are there two bugs for the same issue? Can one of them be closed as a dupe?
Comment 10 Ganael LAPLANCHE freebsd_committer 2021-01-25 20:33:09 UTC
Hello Dimitry,

> On stable branches, and for LLVM ports, assertions are disabled
> [...]

So that problem would be related to TBB code only, thanks for those precisions.

> That said, I will have look at the reproduction files from bug 252892.

Thanks !

> Btw why are there two bugs for the same issue? Can one of them be closed as a
> dupe?

PR #252648 is the master one for handling oneTBB switch.

PR #252892 has then been opened for that specific build issue ; that second PR could be closed, but I think it's not so bad to have another one dedicated to that issue, to avoid polluting the master bug report.

Best regards,
Ganael.
Comment 11 Ganael LAPLANCHE freebsd_committer 2021-01-26 06:39:13 UTC
>> On stable branches, and for LLVM ports, assertions are disabled
>> [...]
>
> So that problem would be related to TBB code only, thanks for those precisions.

Let me correct myself (sorry, I just got it :p): of course you mean assertions on *llvm side* so we are hitting a *llvm assertion*, triggered by oneTbb code...
Comment 12 Dimitry Andric freebsd_committer 2021-01-26 13:16:40 UTC
(In reply to Ganael LAPLANCHE from comment #11)

Yes indeed, exactly that. :) I already found an upstream fix for this particular assertion, and am testing it now. I will probably commit it later today, and set an MFC timeout of 3 days.
Comment 13 Ganael LAPLANCHE freebsd_committer 2021-01-26 15:28:59 UTC
Good news, thanks :)
Comment 14 commit-hook freebsd_committer 2021-01-26 16:53:21 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=e63539f3059728ff58328ac0ecb2a7bf4e2f08e8

commit e63539f3059728ff58328ac0ecb2a7bf4e2f08e8
Author:     Dimitry Andric <dim@FreeBSD.org>
AuthorDate: 2021-01-26 13:07:47 +0000
Commit:     Dimitry Andric <dim@FreeBSD.org>
CommitDate: 2021-01-26 16:51:25 +0000

    Fix clang assertion when compiling the devel/onetbb port

    Merge commit 740a164de from llvm git (by Richard Smith):

      PR46377: Fix dependence calculation for function types and typedef
      types.

      We previously did not treat a function type as dependent if it had a
      parameter pack with a non-dependent type -- such a function type depends
      on the arity of the pack so is dependent even though none of the
      parameter types is dependent. In order to properly handle this, we now
      treat pack expansion types as always being dependent types (depending on
      at least the pack arity), and always canonically being pack expansion
      types, even in the unusual case when the pattern is not a dependent
      type. This does mean that we can have canonical types that are pack
      expansions that contain no unexpanded packs, which is unfortunate but
      not inaccurate.

      We also previously did not treat a typedef type as
      instantiation-dependent if its canonical type was not
      instantiation-dependent. That's wrong because instantiation-dependence
      is a property of the type sugar, not of the type; an
      instantiation-dependent type can have a non-instantiation-dependent
      canonical type.

    Merge commit 9cf98d26e from llvm git (by Richard Smith):

      PR46637: Fix handling of placeholder types in trailing-return-types.

      Only permit a placeholder type in a trailing-return-type if it would
      also have been permitted in the decl-specifier sequence of a
      corresponding declaration with no trailing-return-type. The standard
      doesn't actually say this, but this is the only thing that makes sense.

      Also fix handling of an 'auto' in a trailing-return-type in a parameter
      of a generic lambda. We used to crash if we saw such a thing.

    Merge commit 234f51a65 from llvm git (by Richard Smith):

      Don't crash if we deserialize a pack expansion type whose pattern
      contains no packs.

      Fixes a regression from 740a164dec483225cbd02ab6c82199e2747ffacb.

    PR:             252892
    Reported by:    thierry
    MFC after:      3 days

 .../clang/include/clang/AST/ASTContext.h           |  10 +-
 .../llvm-project/clang/include/clang/AST/Type.h    |  13 +--
 .../clang/include/clang/AST/TypeProperties.td      |   3 +-
 .../clang/include/clang/Basic/TypeNodes.td         |   2 +-
 .../clang/include/clang/Sema/DeclSpec.h            |   9 ++
 .../llvm-project/clang/include/clang/Sema/Sema.h   |   2 +
 contrib/llvm-project/clang/lib/AST/ASTContext.cpp  |  34 +++---
 contrib/llvm-project/clang/lib/AST/ASTImporter.cpp |   3 +-
 contrib/llvm-project/clang/lib/AST/Type.cpp        |   9 +-
 .../llvm-project/clang/lib/CodeGen/CGDebugInfo.cpp |   1 -
 .../clang/lib/CodeGen/CodeGenFunction.cpp          |   1 -
 contrib/llvm-project/clang/lib/Sema/SemaExpr.cpp   |   1 -
 contrib/llvm-project/clang/lib/Sema/SemaLambda.cpp |   3 +-
 .../clang/lib/Sema/SemaTemplateDeduction.cpp       |   7 ++
 .../clang/lib/Sema/SemaTemplateVariadic.cpp        |   3 +-
 contrib/llvm-project/clang/lib/Sema/SemaType.cpp   | 119 +++++++++++----------
 16 files changed, 121 insertions(+), 99 deletions(-)
Comment 15 Ganael LAPLANCHE freebsd_committer 2021-01-26 17:32:37 UTC
Thanks a lot Dimitry !
Comment 16 Thierry Thomas freebsd_committer 2021-01-26 18:28:58 UTC
Thanks Dimitry, this was quick! Could please also bump newvers, so that the ports can check $OSVERSION ?
Comment 17 Dimitry Andric freebsd_committer 2021-01-26 18:40:59 UTC
(In reply to Thierry Thomas from comment #16)
Sure, though I'll probably get some grumbling from people that have to rebuild world yet again. :-)
Comment 18 commit-hook freebsd_committer 2021-01-26 18:44:45 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=2cf84258922f306a3f84866685d2f5346f67db58

commit 2cf84258922f306a3f84866685d2f5346f67db58
Author:     Dimitry Andric <dim@FreeBSD.org>
AuthorDate: 2021-01-26 18:43:55 +0000
Commit:     Dimitry Andric <dim@FreeBSD.org>
CommitDate: 2021-01-26 18:43:55 +0000

    Bump __FreeBSD_version after e63539f3059728ff58328ac0ecb2a7bf4e2f08e8

    This is to allow ports to detect the clang fix applied in the above
    commit.

    PR:             252892
    MFC after:      3 days

 sys/sys/param.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Comment 19 commit-hook freebsd_committer 2021-01-29 23:29:51 UTC
A commit in branch stable/13 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=010196adcfaf2bb610725394d40691874b4ff2af

commit 010196adcfaf2bb610725394d40691874b4ff2af
Author:     Dimitry Andric <dim@FreeBSD.org>
AuthorDate: 2021-01-26 13:07:47 +0000
Commit:     Dimitry Andric <dim@FreeBSD.org>
CommitDate: 2021-01-29 23:25:53 +0000

    Fix clang assertion when compiling the devel/onetbb port

    Merge commit 740a164de from llvm git (by Richard Smith):

      PR46377: Fix dependence calculation for function types and typedef
      types.

      We previously did not treat a function type as dependent if it had a
      parameter pack with a non-dependent type -- such a function type depends
      on the arity of the pack so is dependent even though none of the
      parameter types is dependent. In order to properly handle this, we now
      treat pack expansion types as always being dependent types (depending on
      at least the pack arity), and always canonically being pack expansion
      types, even in the unusual case when the pattern is not a dependent
      type. This does mean that we can have canonical types that are pack
      expansions that contain no unexpanded packs, which is unfortunate but
      not inaccurate.

      We also previously did not treat a typedef type as
      instantiation-dependent if its canonical type was not
      instantiation-dependent. That's wrong because instantiation-dependence
      is a property of the type sugar, not of the type; an
      instantiation-dependent type can have a non-instantiation-dependent
      canonical type.

    Merge commit 9cf98d26e from llvm git (by Richard Smith):

      PR46637: Fix handling of placeholder types in trailing-return-types.

      Only permit a placeholder type in a trailing-return-type if it would
      also have been permitted in the decl-specifier sequence of a
      corresponding declaration with no trailing-return-type. The standard
      doesn't actually say this, but this is the only thing that makes sense.

      Also fix handling of an 'auto' in a trailing-return-type in a parameter
      of a generic lambda. We used to crash if we saw such a thing.

    Merge commit 234f51a65 from llvm git (by Richard Smith):

      Don't crash if we deserialize a pack expansion type whose pattern
      contains no packs.

      Fixes a regression from 740a164dec483225cbd02ab6c82199e2747ffacb.

    PR:             252892
    Reported by:    thierry

    (cherry picked from commit e63539f3059728ff58328ac0ecb2a7bf4e2f08e8)

    Bump __FreeBSD_version after e63539f3059728ff58328ac0ecb2a7bf4e2f08e8

    This is to allow ports to detect the clang fix applied in the above
    commit.

    PR:             252892

    (cherry picked from commit 2cf84258922f306a3f84866685d2f5346f67db58)

 .../clang/include/clang/AST/ASTContext.h           |  10 +-
 .../llvm-project/clang/include/clang/AST/Type.h    |  13 +--
 .../clang/include/clang/AST/TypeProperties.td      |   3 +-
 .../clang/include/clang/Basic/TypeNodes.td         |   2 +-
 .../clang/include/clang/Sema/DeclSpec.h            |   9 ++
 .../llvm-project/clang/include/clang/Sema/Sema.h   |   2 +
 contrib/llvm-project/clang/lib/AST/ASTContext.cpp  |  34 +++---
 contrib/llvm-project/clang/lib/AST/ASTImporter.cpp |   3 +-
 contrib/llvm-project/clang/lib/AST/Type.cpp        |   9 +-
 .../llvm-project/clang/lib/CodeGen/CGDebugInfo.cpp |   1 -
 .../clang/lib/CodeGen/CodeGenFunction.cpp          |   1 -
 contrib/llvm-project/clang/lib/Sema/SemaExpr.cpp   |   1 -
 contrib/llvm-project/clang/lib/Sema/SemaLambda.cpp |   3 +-
 .../clang/lib/Sema/SemaTemplateDeduction.cpp       |   7 ++
 .../clang/lib/Sema/SemaTemplateVariadic.cpp        |   3 +-
 contrib/llvm-project/clang/lib/Sema/SemaType.cpp   | 119 +++++++++++----------
 sys/sys/param.h                                    |   2 +-
 17 files changed, 122 insertions(+), 100 deletions(-)
Comment 20 commit-hook freebsd_committer 2021-01-29 23:29:52 UTC
A commit in branch stable/13 references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=010196adcfaf2bb610725394d40691874b4ff2af

commit 010196adcfaf2bb610725394d40691874b4ff2af
Author:     Dimitry Andric <dim@FreeBSD.org>
AuthorDate: 2021-01-26 13:07:47 +0000
Commit:     Dimitry Andric <dim@FreeBSD.org>
CommitDate: 2021-01-29 23:25:53 +0000

    Fix clang assertion when compiling the devel/onetbb port

    Merge commit 740a164de from llvm git (by Richard Smith):

      PR46377: Fix dependence calculation for function types and typedef
      types.

      We previously did not treat a function type as dependent if it had a
      parameter pack with a non-dependent type -- such a function type depends
      on the arity of the pack so is dependent even though none of the
      parameter types is dependent. In order to properly handle this, we now
      treat pack expansion types as always being dependent types (depending on
      at least the pack arity), and always canonically being pack expansion
      types, even in the unusual case when the pattern is not a dependent
      type. This does mean that we can have canonical types that are pack
      expansions that contain no unexpanded packs, which is unfortunate but
      not inaccurate.

      We also previously did not treat a typedef type as
      instantiation-dependent if its canonical type was not
      instantiation-dependent. That's wrong because instantiation-dependence
      is a property of the type sugar, not of the type; an
      instantiation-dependent type can have a non-instantiation-dependent
      canonical type.

    Merge commit 9cf98d26e from llvm git (by Richard Smith):

      PR46637: Fix handling of placeholder types in trailing-return-types.

      Only permit a placeholder type in a trailing-return-type if it would
      also have been permitted in the decl-specifier sequence of a
      corresponding declaration with no trailing-return-type. The standard
      doesn't actually say this, but this is the only thing that makes sense.

      Also fix handling of an 'auto' in a trailing-return-type in a parameter
      of a generic lambda. We used to crash if we saw such a thing.

    Merge commit 234f51a65 from llvm git (by Richard Smith):

      Don't crash if we deserialize a pack expansion type whose pattern
      contains no packs.

      Fixes a regression from 740a164dec483225cbd02ab6c82199e2747ffacb.

    PR:             252892
    Reported by:    thierry

    (cherry picked from commit e63539f3059728ff58328ac0ecb2a7bf4e2f08e8)

    Bump __FreeBSD_version after e63539f3059728ff58328ac0ecb2a7bf4e2f08e8

    This is to allow ports to detect the clang fix applied in the above
    commit.

    PR:             252892

    (cherry picked from commit 2cf84258922f306a3f84866685d2f5346f67db58)

 .../clang/include/clang/AST/ASTContext.h           |  10 +-
 .../llvm-project/clang/include/clang/AST/Type.h    |  13 +--
 .../clang/include/clang/AST/TypeProperties.td      |   3 +-
 .../clang/include/clang/Basic/TypeNodes.td         |   2 +-
 .../clang/include/clang/Sema/DeclSpec.h            |   9 ++
 .../llvm-project/clang/include/clang/Sema/Sema.h   |   2 +
 contrib/llvm-project/clang/lib/AST/ASTContext.cpp  |  34 +++---
 contrib/llvm-project/clang/lib/AST/ASTImporter.cpp |   3 +-
 contrib/llvm-project/clang/lib/AST/Type.cpp        |   9 +-
 .../llvm-project/clang/lib/CodeGen/CGDebugInfo.cpp |   1 -
 .../clang/lib/CodeGen/CodeGenFunction.cpp          |   1 -
 contrib/llvm-project/clang/lib/Sema/SemaExpr.cpp   |   1 -
 contrib/llvm-project/clang/lib/Sema/SemaLambda.cpp |   3 +-
 .../clang/lib/Sema/SemaTemplateDeduction.cpp       |   7 ++
 .../clang/lib/Sema/SemaTemplateVariadic.cpp        |   3 +-
 contrib/llvm-project/clang/lib/Sema/SemaType.cpp   | 119 +++++++++++----------
 sys/sys/param.h                                    |   2 +-
 17 files changed, 122 insertions(+), 100 deletions(-)