This PR refactors the ASTDumper to make it more structured, less mistake-prone, and more amenable to future changes. For example:
```cpp
// Before:
void visitUnresolvedDotExpr(UnresolvedDotExpr *E) {
printCommon(E, "unresolved_dot_expr")
<< " field '" << E->getName() << "'";
PrintWithColorRAII(OS, ExprModifierColor)
<< " function_ref=" << getFunctionRefKindStr(E->getFunctionRefKind());
if (E->getBase()) {
OS << '\n';
printRec(E->getBase());
}
PrintWithColorRAII(OS, ParenthesisColor) << ')';
}
// After:
void visitUnresolvedDotExpr(UnresolvedDotExpr *E, StringRef label) {
printCommon(E, "unresolved_dot_expr", label);
printFieldQuoted(E->getName(), "field");
printField(E->getFunctionRefKind(), "function_ref", ExprModifierColor);
if (E->getBase()) {
printRec(E->getBase());
}
printFoot();
}
```
* Values are printed through calls to base class methods, rather than direct access to the underlying `raw_ostream`.
* These methods tend to reduce the chances of bugs like missing/extra spaces or newlines, too much/too little indentation, etc.
* More values are quoted, and unprintable/non-ASCII characters in quoted values are escaped before printing.
* Infrastructure to label child nodes now exists.
* Some weird breaks from the normal "style", like `PatternBindingDecl`'s original and processed initializers, have been brought into line.
* Some types that previously used ad-hoc dumping functions, like conformances and substitution maps, are now structured similarly to the dumper classes.
* I've fixed the odd dumping bug along the way. For example, distributed actors were only marked `actor`, not `distributed actor`.
This PR doesn't change the overall style of AST dumps; they're still pseudo-S-expressions. But the logic that implements this style is now isolated into a relatively small base class, making it feasible to introduce e.g. JSON dumping in the future.
Issue a deprecation warning in Swift 5 and an error in Swift 6 when we encounter @UIApplicationMain and @NSApplicationMain. These attributes are unnecessary now that @main works with UIApplicationDelegate and NSApplicationDelegate. As these conformances are required when working with the corresponding attributes, we can migrate users off of them by replacing them with @main.
The compiler enters "script" mode if there is a file called
`main.swift`, or if there is only one file. Parsing files as a script
means that anything in the file is interpreted as top-level code, which
is incompatible with a valid @main-annotated struct, so an error is
emitted.
Unfortunately, it is intentional in many cases, and the diagnostic
didn't provide anything actionable to indicate that the explicit main
function is intentional and that the file being passed in is not
actually a top-level context.
The new note indicates that passing `-parse-as-library` to the compiler
invocation will fix it if the explicit main function is intentional.
This patch contains the updates for the tests. The merge removes the
`-async-main` flag, so the tests using that flag fail on that.
Additionally, the tests reflect the newer behavior of the main
resolution. `async_main_resolution` verifies that we're not preferring
an async function over a synchronous function, and vice versa.
This is also verified in `where_clause_main_resolution`, where we select
a main function using various configuration typealiases.
Finally, we only select a valid, usable main function. The old machinery
could select one sort of at random (technically it selected the first
overload declared in the source file) if an error occurred. Errors that
resulted in this behavior included a missing valid function, or an
ambiguous overload. In the case of the missing valid function, the
function returned would be from an invalid location if one existed,
which was called from `$main`. `$main` had sufficient context to realize
that the main function being called was not valid, and would emit an
error saying why. It would be better to realize that we're not getting a
valid main function earlier, and later we can emit notes saying why each
function called main could not be selected.
We've already generated the parts necessary to handle `@main` during
SILGen. Keeping the attribute on the struct means that re-ingesting the
SIL will fail because it tries to re-create the implicit `$main`
function resulting in the following error message:
error: invalid redeclaration of synthesized static method '$main()'
static func $main()
Previously, it was possible for $main to be made dynamic by passing
-enable-implicit-dynamic. That has always been a problem in asserts
builds because a direct function_ref to $main is created in the main
function. More recently, it has become a problem in non-asserts builds
because the dynamic replacements are now in the IR module but are not in
the TBD file.
Here, the function is marked as not dynamic.
rdar://84962693
Synthesizing the body of a throwing main didn't take into account the
implicit try. We were creating one, then just leaving it off. This patch
actually passes the modified AST branch through to the emitted return
statement, rather than just keeping the call.
As a separate note, I hit an assert saying that a source range must
either be completely invalid or completely valid when just passing the
invalid SourceLoc to the TryExpr. I've changed it to just take the
SourceLoc from the implicit CallExpr, which should be the same as the
invalid SourceLoc, but seems to inherit it from another place.
In debug configurations, fatal error messages include file & line number information. This update presents this information in a format matching the diagnostic conventions used by the compiler, which can be a slight productivity boost.
Code compiled with optimizations enabled (which is most production code) does not output this information, so it isn’t affected by this change.
Original format:
Fatal error: A suffusion of yellow: file calc.swift, line 5
New format:
calc.swift:5: Fatal error: A suffusion of yellow
Resolves rdar://68484891
The tests for the @main and @_originallyDefinedIn attributes were
insufficiently general to get decent platform coverage. Generalize
them to at least run on iOS, with appropriate %target-run'ification.
SE-0281 was accepted with the modification that the main function should
be allowed to be throwing. Here support for enabling that is added.
Support is implemented in two steps:
(1) The $main wrapper function is modified to be throwing
static func $main() throws {
return try main()
}
whenever the main function is throwing (it remains non-throwing when
$main is not throwing).
(2) The @main entry point is modified to be
sil [ossa] @main : $@convention(c) (Int32, UnsafeMutablePointer<Optional<UnsafeMutablePointer<Int8>>>) -> Int32 {
entry(%argc : $Int32, %argv : $UnsafeMutablePointer<Optional<UnsafeMutablePointer<Int8>>>):
%the_main_type = metatype $@thin TheMainType.Type
%the_main_func = function_ref @`TheMainType.main()` : $@convention(method) (@thin TheMainType.Type) -> @error Error
try_apply %the_main_func(%the_main_type) : $@convention(method) (@thin TheMainType.Type) -> @error Error, normal success, error failure
success(%_ : $()):
%success_code_builtin_int32 = integer_literal $Builtin.Int32, 0
br bb1(%success_code_builtin_int32 : $Builtin.Int32)
failure(%error : @owned $Error):
%_ = builtin "errorInMain"(%error : $Error) : $()
end_lifetime %error : $Error
%error_code_builtin_int32 = integer_literal $Builtin.Int32, 1
br bb1(%error_code_builtin_int32 : $Builtin.Int32)
exit(%code_builtin_int32 : $Builtin.Int32):
%code = struct $Int32 (%code_builtin_int32 : $Builtin.Int32)
return %code : $Int32
}
whenever the main function is throwing (and consequently $main also is).
In the non-throwing case, (a) the try_apply instruction is replaced with an
apply instruction, (b) the body of the success block is appended to the
entry block, and (c) the success and failure blocks are removed.
Previously the @main attribute could only be applied to
NominalTypeDecls. Here, that limitation is lifted so that the attribute
can be applied to ExtensionDecls.
When a type (class, enum, or struct) is annotated @main, it is required
to provide a function with the following signature:
static func main() -> ()
That function will be called when the executable the type is defined
within is launched.
This is required to correctly use the mock SDK when the SDK overlay is
built and tested separately. (Otherwise, the mock SDK might not get
used, because the overlay SDK options would expand from the
%-substitution, appear first on the command line, and shadow the mock
SDK in the search path).
Swift SVN r25185
This isn't being used for much yet, but it will allow us to tell whether
something is an app target even at the module-merging stage, which is a
better way to tell if something is an app than whether it has a bridging
header.
We'll also need this if we ever take advantage of reusing "partial modules"
(serialized ASTs for other parts of the module that aren't affected by the
current source file) for compiling source files in incremental builds;
unfortunately that's unlikely given our dependency model.
Swift SVN r24531
