[all-commits] [llvm/llvm-project] 5cc5d7: Fix recursive error for constraints depending on i...

[Aaron Ballman via All-commits]

  Branch: refs/heads/release/16.x
  Home:   https://github.com/llvm/llvm-project
  Commit: 5cc5d71a10077f4ce4c83ac7c2aee13dc8ea2739
      https://github.com/llvm/llvm-project/commit/5cc5d71a10077f4ce4c83ac7c2aee13dc8ea2739
  Author: Erich Keane <erich.keane at intel.com>
  Date:   2023-01-27 (Fri, 27 Jan 2023)

  Changed paths:
    M clang/include/clang/Sema/Sema.h
    M clang/lib/Sema/SemaConcept.cpp
    M clang/test/SemaTemplate/concepts-recursive-inst.cpp

  Log Message:
  -----------
  Fix recursive error for constraints depending on itself incorrectly

Fixes: #60323

https://github.com/llvm/llvm-project/issues/60323

The problem is that we are profiling the 'Expr' components directly,
however when they contain an unresolved lookup, those canonicalize
identically.  The result was the two versions of calls to 'go' were
canonicalized identically.

This patch fixes this by ensuring we consider the declaration the
constraint is attached to, when possible.  When not, we skip the
diagnostic.

The result is that we are relaxing our diagnostic in some cases (Of
which I couldn't come up with a reproducer), such that we might see
overflows when evaluating constraints that depend on themselves in a way
that they are not attached to a declaration directly, such as if
they are nested requirements, though the hope is this won't be a
problem, since the 'parent' named constraint would catch this.  I'm
hopeful that the 'worst case' is that we catch recursion 'later' in the
process, instead of immediately.

(cherry picked from commit 42667563721e139a93ab886119ea2780ebc3fecc)


  Commit: 0764636b95f1b6f523202a291b9534eb826dd715
      https://github.com/llvm/llvm-project/commit/0764636b95f1b6f523202a291b9534eb826dd715
  Author: Alexey Lapshin <a.v.lapshin at mail.ru>
  Date:   2023-01-27 (Fri, 27 Jan 2023)

  Changed paths:
    M llvm/lib/Support/Parallel.cpp

  Log Message:
  -----------
  [Support] Avoid using main thread for llvm::parallelFor().

The llvm::parallelFor() uses threads created by ThreadPoolExecutor as well as main thread.
The index for the main thread matches with the index for the first thread created by ThreadPoolExecutor.
It results in that getThreadIndex returns the same value for different threads.
To avoid thread index clashing - do not use main thread for llvm::parallelFor():

parallel::TaskGroup TG;
for (; Begin + TaskSize < End; Begin += TaskSize) {
  TG.spawn([=, &Fn] {
    for (size_t I = Begin, E = Begin + TaskSize; I != E; ++I)
      Fn(I);
  });
}
for (; Begin != End; ++Begin)    <<<< executed by main thread.
  Fn(Begin);                     <<<<
return;                          <<<<

Differential Revision: https://reviews.llvm.org/D142317

(cherry picked from commit 10a796a0beb22ec604b3038b544cc9058facea79)


  Commit: 84f3164c1d9ce024f59221dcfbc8ab050de73748
      https://github.com/llvm/llvm-project/commit/84f3164c1d9ce024f59221dcfbc8ab050de73748
  Author: Aaron Ballman <aaron at aaronballman.com>
  Date:   2023-01-27 (Fri, 27 Jan 2023)

  Changed paths:
    M clang/docs/LanguageExtensions.rst
    M clang/include/clang/Basic/DiagnosticParseKinds.td
    M clang/lib/Parse/ParseExpr.cpp
    M clang/test/C/C2x/n2350.c
    M clang/test/C/drs/dr4xx.c
    M clang/test/CXX/drs/dr4xx.cpp

  Log Message:
  -----------
  Stop diagnosing member and array access in offsetof as an extension

This was a mistake from e7300e75b51a7e7d4e81975b4be7a6c65f9a8286
(https://reviews.llvm.org/D133574) caused by us accidentally tracking
an older copy of the C DR list for DR496. The text in
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2396.htm#dr_496 makes
it clear that subobjects are allowed, which means member and array
access expressions are allowed.

This backs out the changes from the previous commit that relate to this
diagnostic.

(cherry picked from commit 63d6b8be6cf2422228a1a8800d85a11be469c6e2)


Compare: https://github.com/llvm/llvm-project/compare/a28dd0170bac...84f3164c1d9c