In Swift 6 and later, whitespace is no longer permitted between an
attribute name and the opening parenthesis. Update the parser so that
in Swift 6+, a `(` without preceding whitespace is always treated as
the start of the argument list, while a '(' with preceding whitespace is
considered the start of the argument list _only when_ it is unambiguous.
This change makes the following closure be parsed correctly:
{ @MainActor (arg: Int) in ... }
rdar://147785544
This can help work around problems when the names of a C++ declaration
and a Swift declaration would collide, or to temporarily work around
compiler bugs.
rdar://152838988&140802127&158843666
Also '#error', '#warning', and '#sourceLocation'.
Other call-like syntax (call expression, macro expansion, and custom
attribtues) requires '(' on the same line as the callee. For consistency,
built-in attributes and built-in directives should also ignore '(' on
next line.
This is a common mistake made more common be suggestions of existing diagnostic
that tell users not to use a 'copy' dependency.
Report a diagnostic error rather than crashing the compiler. Fix the diagnostic
output to make sense relative to the source location.
Fixes rdar://154136015 ([nonescapable] compiler assertion with @_lifetime(x: inout x))
Begin accepting the attribute in the form of `@cdecl(cName)`, using an
identifier instead of a string.
For ease of landing this change we still accept the string form. We
should stop accepting it before making this feature available in
production.
Implements SE-0460 -- the non-underscored version of @specialized.
It allows to specify "internal" (not abi affecting) specializations.
rdar://150033316
By default (currently) the closure passed to a parameter with `@_inheritActorContext`
would only inherit isolation from `nonisolated`, global actor isolated or actor
context when "self" is captured by the closure. `always` changes this behavior to
always inherit actor isolation from context regardless of whether it's captured
or not.
This wasn't really sound since it could result in source ranges that
have different buffers for the start and end loc. Instead, adjust
the parser logic to look at the brace range.
Operator function parsing has a heuristics to determine if `<` a part of
the operator name or the generic parameter clause. Handle `let` there
because value generics uses it.
rdar://149556573
SwiftSyntaxParser is already doing this, and we already diagnosed it in Sema anyway, so we’re just moving that diagnostic earlier so the ASTGen testing mode is happy. Also adding compiler tests for it.
Macro-related tests are not included in this commit; they require matching swift-syntax changes which are being negotiated.
