This lets us make some more assumptions in the next commit, but I
think it's also just a nice cleanup to /not/ allow random predicates
here.
There were three callers of this API:
- PrintAST, which was using PrintOptions::shouldPrint but /also/
incorrectly notifying listeners that a declaration would be skipped.
- (IDE) Interface generation, which uses PrintOptions::shouldPrint to
count how many "inherits" there will be.
- SwiftDocSupport's reportRelated, which does no filtering at all.
Creating a PrintOptions here is a little more expensive, but still.
No intended functionality change.
Previously, we wouldn't escape `Type` and `Protocol` at all in the
ASTPrinter, which lead to unfortunate build failures while compiling an
interface.
Instead, make sure we escape them whenever we print a name that's a type
member. Except for methods, which are erroneously allowed to be called
`Type` and `Protocol`.
rdar://49858651
Previously, we would print multi-line string literals with single quotes, which were not re-parseable. Instead, re-escape their contents and print them out escaped.
Before conditional conformances, the archetypes in conformance
extensions (i.e. extension Foo: SomeProtocol) were equivalent to those
in the type decl, with the same protocol bounds and so on. The code for
printing "synthesized" members relied on this fact. This commit teaches
that code to deal with archetypes in the conditional conformance
extension when required.
Fixes rdar://problem/36553066 and SR-6930.
Implement exhaustiveness checking in Sema with rich error messages. The
algorithm used is a variant of the one described in Fengyun Liu's paper
"A Generic Algorithm for Checking Exhaustivity of Pattern Matching"
published in the EPFL conference, and Luc Maranget's seminal paper
"Warnings for Pattern Matching"
The Space Engine views pattern matching as a problem of projecting the
scrutinee of a pattern-match into a "Space", then iteratively
constructing a Space from the cases. Taking the difference of this
master space and the covered spaces yields the "holes" left over or
reveals a completely covered space.
The algorithm also extends trivially to redundancy checks in patterns,
but that check is already implemented in SILGen and this algorithm does
not improve upon it.
That is, if you have this declaration:
struct Outer {
struct Inner {
// ...
}
}
and you're just printing 'Inner', print it like this:
struct Outer.Inner {
// ...
}
This comes up with the ClangImporter's import-as-member feature, and
is also about to affect how error code enums are imported as well.
This is currently only enabled in certain contexts: always when
printing interfaces, and for types (but not other members) when
printing declarations for Quick Help.
rdar://problem/28208090
1. Make sure the actions taken by fixits are reflected in diagnostics messages.
2. Issue missing cases diagnostics at the start of the switch statement instead of its end.
3. Use <#code#> instead of <#Code#> in the stub.
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.
