For now, just force any pending callbacks before doing the structure
callbacks. This should be fine, since we are always about to print
*something* that isn't whitespace, so there is no change in location.
As a first foray into annotating attribute, add tags around attribute
names. For now, treat any decl-modifiers as keywords. We will also want
to wrap the whole attribute (including any parameters) into tags as
well, but that will require more work in the callback hanlding.
Also factor the attribute printing to handle any special cases early,
which will simplify wrapping attributes in tags, since we can then just
put the whole switch intside the pre/post callbacks.
rdar://problem/24292226
I want to start using this for other things like function types and
attributes, so rename it to reflect the new scope. I'm not really happy
with "PrintStructureKind", etc. but haven't come up with anything
better so far.
Try to match the original spelling of static/class in diagnostics and
when printing the AST. Also fixes cases with
PrintOptions.PrintImplicitAttrs = false, where we would just print
'class', which was not valid code.
Start threading all keyword (and contextual keyword) printing through
printName, and add a new PrintNameContext for keywords. For now we just
pass this through without changing behaviour.
Also add an operator<< for printing from the tok:: kind for keywords,
which makes it much more convenient for performing the required
callbacks.
rdar://problem/24292226
The current approach of visiting the param decl won't work when we want
to visit the parameters of function *types*, or when visiting tuple
elements (which aren't themselves decls).
rdar://problem/24292226
As the initial step, we remove any synthesized extensions requiring a tuple's conforming to nominals, which
never happens. This will remove multiple useless synthesized extensions for Dictionary.
We can have multiple printDeclPre callbacks pending (e.g top-level-code
decls), so use a vector to ensure we don't lose the earlier callbacks.
We also may end up calling printDeclPost without forcing the
corresponding printDeclPre first if the decl doesn't actually print
anything (e.g. an if-config statement when skipping those). So add a
wrapper callPrintDeclPost that can check for this and skip both
callbacks. In theory, we could handle this case by instead making all
ast nodes go through something like shouldPrint() and making an
invariant that something will be printed if and only if shouldPrint
returns true. However, that is not an obvious win, because it forces us
to walk all the first-level statements and decls inside a top-level-code
decl to determine if anything will be printed, and it also means we can
never make local decisions about whether something will be printed. For
now, I've chosen to maintain flexibility by recovering from unprinted
decls.
Finally, add a bunch of assertions to try to keep callbacks sane.
By moving enum element handling completely to shouldPrint(), which is
called in visi(). We don't print enum element decls as part of their
decl context so it's not correct to use shouldPrintInContext() here
anyway.
The problem was that shouldPrint returned true, but shouldPrintInContext
returned false, so we called printDeclPost without ever printing
anything and therefore never calling the pending printDeclPre. Also
remove the avoidPrintDeclPost in the annotation printer, since it was
incorrectly assuming that avoidPrintDeclPost was paired with
printDeclPre (it's not clear to me that it isn't sometimes paired
though...).
Future work: remove or properly document the difference between the two
shouldPrint* variants; and ensure that callbacks will always be paired
even if we don't end up printing anything. Also verify that
avoidPrintDeclPost behaves correctly with respect to printDeclPre being
called (or not).
When performing Swift API dumps, it's helpful to avoid putting
redundant APIs into the results. Therefore, filter out any APIs that
are overrides of another API or are witnesses for a protocol
requirement, since the original definition (that doesn't override any
other or is a protocol requirement) is what determines the APIs name.
... for the fully annotated declarations. More substructure more better.
This has to go through a callback mechanism similar to printDeclLoc and
printDeclPre since it should be scheduled after both of those are
printed.
rdar://problem/24292226
Similarly to how we've always handled parameter types, we
now recursively expand tuples in result types and separately
determine a result convention for each result.
The most important code-generation change here is that
indirect results are now returned separately from each
other and from any direct results. It is generally far
better, when receiving an indirect result, to receive it
as an independent result; the caller is much more likely
to be able to directly receive the result in the address
they want to initialize, rather than having to receive it
in temporary memory and then copy parts of it into the
target.
The most important conceptual change here that clients and
producers of SIL must be aware of is the new distinction
between a SILFunctionType's *parameters* and its *argument
list*. The former is just the formal parameters, derived
purely from the parameter types of the original function;
indirect results are no longer in this list. The latter
includes the indirect result arguments; as always, all
the indirect results strictly precede the parameters.
Apply instructions and entry block arguments follow the
argument list, not the parameter list.
A relatively minor change is that there can now be multiple
direct results, each with its own result convention.
This is a minor change because I've chosen to leave
return instructions as taking a single operand and
apply instructions as producing a single result; when
the type describes multiple results, they are implicitly
bound up in a tuple. It might make sense to split these
up and allow e.g. return instructions to take a list
of operands; however, it's not clear what to do on the
caller side, and this would be a major change that can
be separated out from this already over-large patch.
Unsurprisingly, the most invasive changes here are in
SILGen; this requires substantial reworking of both call
emission and reabstraction. It also proved important
to switch several SILGen operations over to work with
RValue instead of ManagedValue, since otherwise they
would be forced to spuriously "implode" buffers.
We already know to print one before printing the body brace (if we're
printing function bodies), and it certainly doesn't belong in the
*name* portion of the decl.
Also add a cursor info test with a deinit.
This splits the printDeclNamEndLoc callback into NameEndLoc and
NameOrSignatureEndLoc variants to differentiate whether or not
signatures are included. All existing clients move to
NameOrSignatureEndLoc to maintain the current behaviour. I'm still not
completely happy with how these are named, but I dont' have any better
ideas right now.
rdar://problem/24292226
There's a group of methods in `DeclContext` with names that start with *is*,
such as `isClassOrClassExtensionContext()`. These names suggests a boolean
return value, while the methods actually return a type declaration. This
patch replaces the *is* prefix with *getAs* to better reflect their interface.
For a concrete type, members from its conforming protocols' extensions can be hard
to manually surface. In this commit, when printing Swift modules, we start to replicate these
extensions and synthesize them as if they are the concrete type's native extensions.
Credit to Doug for suggesting this practice.
Adds an associatedtype keyword to the parser tokens, and accepts either
typealias or associatedtype to create an AssociatedTypeDecl, warning
that the former is deprecated. The ASTPrinter now emits associatedtype
for AssociatedTypeDecls.
Separated AssociatedType from TypeAlias as two different kinds of
CodeCompletionDeclKinds. This part probably doesn’t turn out to be
absolutely necessary currently, but it is nice cleanup from formerly
specifically glomming the two together.
And then many, many changes to tests. The actual new tests for the fixits
is at the end of Generics/associated_types.swift.
Introduce a new attribute, swift3_migration, that lets us describe the
transformation required to map a Swift 2.x API into its Swift 3
equivalent. The only transformation understood now is "renamed" (to
some other declaration name), but there's a message field where we can
record information about other changes. The attribute can grow
somewhat (e.g., to represent parameter reordering) as we need it.
Right now, we do nothing but store and validate this attribute.
ASTPrinter of type variables was trying to dig an original type out of the
locator and archetype that opened the type variable in the first place. This
was prone to failure and never helped, so just always print type vars as _.
The affected diagnostics always come out better and this saves a word of storage
for each type variable.
