I misled Argyrios into thinking we only had a wrapper for the name when
we also have one for the whole attribute. Fix that for @escaping and
@autoclosure.
rdar://problem/27867763
To each note with a protocol requirement that is not met, a fixit is
added that inserts a stub for the requirement at the start of the
adoptee's declaration.
Pass through the original Type in addition to the TypeDecl so that we
can distinguish DynamicSelfType with underlying ClassType from just any
old ClassType.
rdar://problem/25158493
Treat it like the static Self type, which is good enough for producing
USRs in CursorInfo. This doesn't handle class dynamic self, which needs
some kind of API change to printTypeRef to make it work.
rdar://problem/25128561
For now, only do this in SourceKit (printQuickHelpDeclaration), but
there are probably other printing modes that should do this.
rdar://problem/24292226
Move the type callbacks into the respective type/typerepr printers so
taht we get these callbacks even when we print the type directly, or in
a nested fashion. Also make the returntype more explicit than just
"inside a function type", since visiting the function type currently
visits the input argument tuple (which is different than e.g. the
function *decl* printing, which walks the parameter list explicitly).
rdar://problem/24292226
The three varieties of 'pending callbacks' made it hard to reason about
how callbacks would be presented to subclasses of ASTPrinter. I
recently added new callbacks that would have made this even more complex
to deal with.
Luckily, it turns out they weren't buying us much, and simply forcing
any pending newlines and indentation to be printed ahead of making
callbacks was almost identical to the old behaviour. One complication is
that we now need to check for clang doc comments up front so we will
emit a newline in the right place.
This also incidentally fixed a bug in Loc vs Decl callback order.
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.
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
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.
... 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.
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
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.
Allow all keywords except for parameter introducers (var/let/inout) to
be argument labels when declaring or calling a
function/initializer/subscript, e.g., this
func touchesMatching(phase: NSTouchPhase, `in` view: NSView?) -> Set<NSTouch>
can now be expressed as
func touchesMatching(phase: NSTouchPhase, in view: NSView?) -> Set<NSTouch>
and the call goes from
event.touchesMatching(phase, `in`: view)
to
event.touchesMatching(phase, in: view)
Fixes [SR-344](https://bugs.swift.org/browse/SR-344) /
rdar://problem/22415674.
When users try to print the interface of a specific type (most often through cursor
infor query of SourceKit), we should simplify the original decls by replacing
archetypes with instantiated types, hiding extension details, and omitting
unfulfilled extension requirements. So the users can get the straight-to-the-point
"type interface". This commit builds the testing infrastructure for this feature,
and implements the first trick that wraps extension contents into the interface body.
This commit also moves some generic testing support from SourceKit to Swift.
Swift SVN r32630
Cleans up AST printing somewhat as well as providing slightly better
type-to-declaration mappings for annotated AST printing and indexing.
Swift SVN r32420
This lets us reliably print and parse opened archetypes across different compiler invocations. Using a source-related locator would be ideal, but that's complicated by the need to manufacture, print, and parse these things during SIL passes, so cop out and burn a UUID for now.
Swift SVN r22385
When a subclass is missing a required initializer, produce an error
within the subclass that mentions the required initializer along with
a Fix-It that provides an initializer stub, e.g.,
required init(coder aDecoder: NSCoder!) {
fatalError("init(coder:) has not been implemented")
}
We take care to insert this stub in the main class, after all of the
initializers (if there are any) or near the beginning of the class (if
there aren't any initializers), and try to match the existing
indentation. If this works out, we should handle unsatisfied protocol
requirements the same way. <rdar://problem/17923210>
Swift SVN r21055
