[all-commits] [llvm/llvm-project] f061a3: [Clang][Sema][Parse] Delay parsing of noexcept-spe...

[Krystian Stasiowski via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: f061a395ffb78215a23e0f503e8ea121ee3b13ad
      https://github.com/llvm/llvm-project/commit/f061a395ffb78215a23e0f503e8ea121ee3b13ad
  Author: Krystian Stasiowski <sdkrystian at gmail.com>
  Date:   2024-04-30 (Tue, 30 Apr 2024)

  Changed paths:
    M clang/docs/ReleaseNotes.rst
    M clang/include/clang/Sema/Sema.h
    M clang/lib/Parse/ParseDecl.cpp
    M clang/lib/Sema/SemaDeclCXX.cpp
    M clang/lib/Sema/SemaExceptionSpec.cpp
    A clang/test/CXX/class/class.mem/class.mem.general/p8.cpp
    A clang/test/CXX/except/except.spec/p13-friend.cpp

  Log Message:
  -----------
  [Clang][Sema][Parse] Delay parsing of noexcept-specifiers in friend function declarations (#90517)

According to [class.mem.general] p8:
> A complete-class context of a class (template) is a
> - function body,
> - default argument,
> - default template argument,
> - _noexcept-specifier_, or
> - default member initializer
>
> within the member-specification of the class or class template.

When testing #90152, it came to my attention that we do _not_ consider
the _noexcept-specifier_ of a friend function declaration to be a
complete-class context (something which the Microsoft standard library
depends on). Although a comment states that this is "consistent with
what other implementations do", the only other implementation that
exhibits this behavior is GCC (MSVC and EDG both late-parse the
_noexcept-specifier_).

This patch changes _noexcept-specifiers_ of friend function declarations
to be late parsed, which is in agreement with the standard & majority of
implementations. Pre-#90152, our existing implementation falls "in
between" the implementation consensus: within non-template classes, we
would not find latter declared members (qualified and unqualified),
while within class templates we would not find latter declared member
when named with a unqualified name, we would find members named with a
qualified name (even when lookup context is the current instantiation).
Therefore, this _shouldn't_ be a breaking change -- any code that didn't
compile will continue to not compile (since a _noexcept-specifier_ is
not part of the deduction substitution
loci (see [temp.deduct.general] p7), and any code which
did compile should continue to do so.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications