In strict concurrency mode some calls could reference a declaration that
is wrapped in one or more function conversion expressions to apply
concurrency related attributes or erase them (such as `@Sendable` or
`@MainActor`). This shouldn't impact constness checking and the checker
should look through such conversions.
Resolves: rdar://148168219
(cherry picked from commit b484e9645d)
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
This is a futile attempt to discourage future use of getType() by
giving it a "scary" name.
We want people to use getInterfaceType() like with the other decl kinds.
Provide ASTWalker with a customization point to specify whether to
check macro arguments (which are type checked but never emitted), the
macro expansion (which is the result of applying the macro and is
actually emitted into the source), or both. Provide answers for the
~115 different ASTWalker visitors throughout the code base.
Fixes rdar://104042945, which concerns checking of effects in
macro arguments---which we shouldn't do.
Replace the use of bool and pointer returns for
`walkToXXXPre`/`walkToXXXPost`, and instead use
explicit actions such as `Action::Continue(E)`,
`Action::SkipChildren(E)`, and `Action::Stop()`.
There are also conditional variants, e.g
`Action::SkipChildrenIf`, `Action::VisitChildrenIf`,
and `Action::StopIf`.
There is still more work that can be done here, in
particular:
- SourceEntityWalker still needs to be migrated.
- Some uses of `return false` in pre-visitation
methods can likely now be replaced by
`Action::Stop`.
- We still use bool and pointer returns internally
within the ASTWalker traversal, which could likely
be improved.
But I'm leaving those as future work for now as
this patch is already large enough.
We currently have a problem with how constantness diagnostics
traverse the AST to look for function calls to diagnose. We
special case closure bodies and don't check them (unless they're
single expression closures) because closure bodies are type-
checked separately and will be covered later. This poses a problem
in certain AST structures, such as what we see with result builders,
because the call expressions are rooted in declarations, which aren't
checked in the closure body type-checking covered by MiscDiag.
This patch fixes the problem by manually checking all closure bodies
and stopping misc diagnostics from checking the bodies separately.
rdar://85737300
When multi-statement closure inference is enabled it's body is
type-checked together with enclosing context, so they could be
walked directly just like single-expressions ones.
When multi-statement closure inference is enabled it's body is
type-checked together with enclosing context, so they could be
walked directly just like single-expressions ones.
Due to the way miscellaneous diagnostics work with closure bodies, the
function argument constantness sema check does not produce proper
diagnostics for single-expression closures. This change fixes the
problem by having the ASTWalker manually walk in the closure body
if it is a single expression.
rdar://65577070
This change includes a fix to allow the diagnostics
for constantness in function arguments to work properly
for constructors. This change also includes some minor
code cleanup in the constantness diagnostic pass.
Currently the function parameter constantness check for functions
annotated with @_semantics("oslog.requires_constant_argument") does
not support ranges (e.g. 0...5, 0..<5). Ranges like this are
considered binary expressions by the compiler. This change adds
support for accepting binary expressions as constant arguments
as long as both arguments to the expression are constant.
rdar://71822563
As of now, the sema checks for os_log allow only string interpolations to be passed
to the log calls. E.g. logger.log(foo("message")) would not be allowed. This PR
relaxes this requirement and allows it as long as foo is annotated as
@_semantics("constant_evaluable").
<rdar://problem/65215054>
