If a var has optional type, e.g.
```
var x: Int?
```
It will be implicitly initialized to `nil`. However, there's a second,
undocumented behavior: tuples of optional type, potentially nested infinitely,
will also be initialized, to tuples of nil.
So this var
```
var w: ((Int?, (), Int?), (Int?, Int?))
```
Will be default-initialized to
```
((nil, (), nil), (nil, nil))
```
We need to handle this inside getDefaultValueStringRepresentation,
otherwise we will crash while emitting partial modules.
Fixes one instance of rdar://51560190
Also oops. This one was a little more involved because the requirements
on a generic typealias don't always carry a Type anymore; sometimes all
you have is the TypeRepr. That should still be okay in practice as long
as we don't start doing that for var/let, which can have part of a type
be inferred but not all of it.
Introduce stored property default argument kind
Fix indent
Assign nil to optionals with no initializers
Don't emit generator for stored property default arg
Fix problem with rebase
Indentation
Serialize stored property default arg text
Fix some tests
Add missing constructor in test
Print stored property's initializer expression
cleanups
preserve switch
complete_constructor
formatting
fix conflict
This improves the test pass rate for the IDE tests on Windows. Some
failures remain. Tests which expect the compiler to be built with
libxml2 cause 2 failures. Another set of tests fail due to `stdint.h`
not being accessible to Windows due to include path ordering. Some
other failures seem to stem from incomplete processing of sources.
We only need to have the identifier during type checking of operator
declarations, so we do not need to restore it from the
PrecedenceGroupDecl during deserialization. We can just use the
deserialized name from the PrecedenceGroupDecl directly if needed.
This does result in one change in behavior. When printing modules, we
previously didn't print 'DefaultPrecedence' for items that had no
precedence specified, but now we will as seen in the test update for
IDE/print_ast_tc_decls.swift.
This allows us to dump it in the generated interface, though it's
still not syntax-highlighted. This is necessary for textual module
interfaces, but it's also just a longstanding request for Xcode's
"Generated Interface" / "Jump to Definition" feature.
rdar://problem/18675831
The information about whether a variable/property is initialized is lost in the
public interface, but is, unfortunately, required because it results in a symbol
for the initializer (if a class/struct `init` is inlined, it will call
initializers for properties that it doesn't initialize itself). This is
important to preserve for TBD file generation.
Using an attribute rather than just a bit on the VarDecl means this fits into
the scheme for module interfaces: textual/valid Swift.
Technically, these operations belong in the ObjectiveC module, where NSObject
is defined. Keep them there. However, we need to build the mock ObjectiveC
overlay with `-disable-objc-attr-requires-foundation-module` now.
These will never work properly because of phase ordering issues with
the current declaration checker design. Since we can always express
the same thing with the protocol inheritance clause instead, just
diagnose this as an error instead of trying to hack around it.
Fixes <rdar://problem/38077232>, <https://bugs.swift.org/browse/SR-5581>.
The “isObjC” bit, once computed, provides the authoritative answer. The presence of
ObjCAttr is mostly incidental, although an implicitly-created one is sometimes
needed to store additional information (“inferred with Swift 3 rules” and a
specific Objective-C name).
hash(into:) needs to be included in expectations; tests looking at synthesized Hashable implementation bodies need to be updated for resilient hashing.
Attach this attribute to VarDecls declared as IUO, and to function decls
that have a result type that is an IUO.
NFC at the moment. Eventually we'll use these to determine where to
implicitly unwrap optional values.
As we do with "where" clauses, print the "inheritance" clauses of
protocols and associated type declarations using the requirement
signature of the protocol rather than the "inherited" list.
In the general case, this is done by reverse engineering the "best"
places for requirements to go from the requirement signature.
Conformance/superclass requirements like Self: Foo and Self.T: Bar defer
to the inheritance clause if they appear there, or are attached to the
protocol where clause or T (respectively) if not. A conformance
requirement like Self.T.U: Baz will go on T (if T is declared in the
protocol being printed).
Same-type requirements always go in where clauses, and specifically a
where clause of an associated type that is mentioned in them, so
something simple like Self.T.U == Int goes on the T associated type
definition, and similarly Self.T.U == Self.V will go on V (it's kinda
nonsense, but also more directly connected to V). There's a left-bias
for cases without an "obvious" choice, meaning something more
complicated like Self.T.U == Foo<Self.V> will end up on T.
Requirements that don't fit elsewhere will go on the
protocol (e.g. Self.AssocTypeFromSuperProtocol == Int).
Textual SIL containing something like: `infix static func ==(a: T, b: T) -> Bool` cannot be parsed and results in an error like:
```
error: 'infix' modifier is not required or allowed on func declarations
```
Interestingly enough, `prefix` and `postfix` attributes do not result in the same kind of errors.
Introduce an algorithm to canonicalize and minimize same-type
constraints. The algorithm itself computes the equivalence classes
that would exist if all explicitly-provided same-type constraints are
ignored, and then forms a minimal, canonical set of explicit same-type
constraints to reform the actual equivalence class known to the type
checker. This should eliminate a number of problems we've seen with
inconsistently-chosen same-type constraints affecting
canonicalization.
When enumerating requirements, always use the archetype anchors to
express requirements. Unlike "representatives", which are simply there
to maintain the union-find data structure used to track equivalence
classes of potential archetypes, archetype anchors are the
ABI-stable canonical types within a fully-formed generic signature.
The test case churn comes from two places. First, while
representatives are *often* the same as the archetype anchors, they
aren't *always* the same. Where they differ, we'll see a change in
both the printed generic signature and, therefore, it's
mangling.
Additionally, requirement inference now takes much greater
care to make sure that the first types in the requirement follow
archetype anchor ordering, so actual conformance requirements occur in
the requirement list at the archetype anchor---not at the first type
that is equivalent to the anchor---which permits the simplification in
IRGen's emission of polymorphic arguments.
There was a ton of complicated logic here to work around
two problems:
- Same-type constraints were not represented properly in
RequirementReprs, requiring us to store them in strong form
and parse them out when printing type interfaces.
- The TypeBase::getAllGenericArgs() method did not do the
right thing for members of protocols and protocol extensions,
and so instead of simple calls to Type::subst(), we had
an elaborate 'ArchetypeTransformer' abstraction repeated
in two places.
Rewrite this code to use GenericSignatures and
GenericFunctionType instead of old-school GenericParamLists
and PolymorphicFunctionType.
This changes the code completion and AST printer output
slightly. A few of the changes are actually fixes for cases
where the old code didn't handle substitutions properly.
A few others are subjective, for example a generic parameter
list of the form <T : Proto> now prints as <T where T : Proto>.
We can add heuristics to make the output whatever we want
here; the important thing is that now we're using modern
abstractions.
We have a special case check for the no-escape-by-default rules for a
computed property setter's newValue argument, which if a closure,
obviously has to be escaping. But, we checked this by checking the
type's overall DeclContext, which unfortunately meant we also made
nested closures escaping implicitly. This fixes that to only tack on
the implicit escaping at the top level for the setter's type.
This fixes several issues:
- By default parent types of alias types are not printed which results in
- Erroneous fixits, for example when casting to 'Notification.Name' from a string, which ends up adding erroneous cast
as "Name(rawValue: ...)"
- Hard to understand types in code-completion results and diagnostics
- When printing with 'fully-qualified' option typealias types are printed erroneously like this "<PARENT>.Type.<TYPEALIAS>"
The change make typealias printing same as nominal types and addresses the above.
- Make sure VarDecls have an associated TypeLoc, like ParamDecls do, then use it for printing the VarDecl's type.
This is done by moving ParamDecl's TypeLoc up to the VarDecl.
This is useful for being able to display the parameter names of function types embedded in VarDecls.
- Use the result TypeLoc of functions for printing. This enables printing parameter names of function types embedded in return types.
- Make sure to annotate attributes while they are printed.
Member operators should be placed within a nominal type (or extension
thereof) that they operate on. Aside from being good style, enforcing
this in the type checker can help with dependency tracking. Addresses
rdar://problem/27536066.
