[all-commits] [llvm/llvm-project] a5a3ef: [Sema] Always search the full function scope conte...

[kepler-5 via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a5a3efa82a77ab7a1c9787ef97b547a4a81f2440
      https://github.com/llvm/llvm-project/commit/a5a3efa82a77ab7a1c9787ef97b547a4a81f2440
  Author: Logan Smith <logan.r.smith0 at gmail.com>
  Date:   2021-05-24 (Mon, 24 May 2021)

  Changed paths:
    M clang/include/clang/Sema/Sema.h
    M clang/lib/Sema/SemaAvailability.cpp
    M clang/lib/Sema/SemaExpr.cpp
    M clang/test/SemaObjC/unguarded-availability.m

  Log Message:
  -----------
  [Sema] Always search the full function scope context if a potential availability violation is encountered

This fixes both https://bugs.llvm.org/show_bug.cgi?id=50309 and https://bugs.llvm.org/show_bug.cgi?id=50310.

Previously, lambdas inside functions would mark their own bodies for later analysis when encountering a potentially unavailable decl, without taking into consideration that the entire lambda itself might be correctly guarded inside an @available check. The same applied to inner class member functions. Blocks happened to work as expected already, since Sema::getEnclosingFunction() skips through block scopes.

This patch instead simply and conservatively marks the entire outermost function scope for search, and removes some special-case logic that prevented DiagnoseUnguardedAvailabilityViolations from traversing down into lambdas and nested functions. This correctly accounts for arbitrarily nested lambdas, inner classes, and blocks that may be inside appropriate @available checks at any ancestor level. It also treats all potential availability violations inside functions consistently, without being overly sensitive to the current DeclContext, which previously caused issues where e.g. nested struct members were warned about twice.

DiagnoseUnguardedAvailabilityViolations now has more work to do in some cases, particularly in functions with many (possibly deeply) nested lambdas and classes, but the big-O is the same, and the simplicity of the approach and the fact that it fixes at least two bugs feels like a strong win.

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