- NominalTypeDecl::computeInterfaceType() crash when parent decl
has error type
- createMaterializeForSetPrototype() crash when parent decl
has error type
- Crashes in ConformanceChecker when decl has error type
Fixes <rdar://problem/21583601>.
Swift SVN r29912
Since each override of a subscript protocol requirement provides
its own materializeForSet, there is no need to do dynamic dispatch,
a peer call to the setter suffices. However, since CodeSynthesis
runs at the AST level, it would create a SubscriptExpr which
overload resolution would later bind to the protocol requirement
subscript rather than the static witness in the extension.
This triggered an assertion. Solve the problem by binding the
actual ConcreteDeclRef of the SubscriptExpr at synthesis time,
and modifying CSGen to special-case SubscriptExprs that already
have a ConcreteDeclRef set.
Fixes <rdar://problem/21370629>.
Swift SVN r29906
When synthesizing designated initializer overrides, set the source location
for the synthesized ConstructorDecl to the location of the opening brace of
the containing ClassDecl. This resolves an assertion failure when constructing
type refinement contexts when whole-program optimization is turned on.
rdar://problem/21233342
Swift SVN r29384
Instead of forcing full application of '{super,self}.init' in the parser, and installing the RebindSelf semantic expr node early, make these constraints to Sema-time checks, and parse '<expr>.init' as a regular postfix production. This is a better separation of concerns, and also opens the door to supporting 'metatype.init()' in more general expression contexts (though that part still needs some follow-up sema work).
Swift SVN r29343
I didn't add anything to the table, just made use of what was already there.
We have plenty of additional calls to getIdentifier that could probably benefit
from this kind of easy access as well.
This commit also removes FOUNDATION_MODULE_NAME and OBJC_MODULE_NAME from
Strings.h. Neither of these is likely to change in the future, and both
already have KnownIdentifiers equivalents in use.
No intended functionality change.
Swift SVN r29292
initializer has been type-checked, rather than a bit for the entire
PatternBindingDecl.
<rdar://problem/21057425> Crash while compiling attached test-app.
Swift SVN r29049
This is necessary to catch things like the rawValue of NS_OPTIONS types, which doesn't directly correspond to a C decl but still needs to be emitted as an external decl.
Swift SVN r28902
Instead, provide the location of the { in a closure expr to the argument formation as
part of the datastructure already used to manage implicit closure arguments in the parser.
Swift SVN r28818
This came out of today's language review meeting.
The intent is to match #available with the attribute
that describes availability.
This is a divergence from Objective-C.
Swift SVN r28484
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
(as well as those for lazy properties, which seem to be working already)
This fixes a problem with @NSManaged properties being declared in an
extension in a generated file you're not supposed to modify, which
unfortunately is exactly how Xcode's generating them these days.
rdar://problem/20821582
Swift SVN r28180
There was a fair amount of code duplication in handling the various
places where @objc could either be explictly specified or be inferred;
centralize these in a new shouldMarkAsObjC() function. NFC
Swift SVN r28125
Introduce basic validation for throwing @objc initializers, e.g., a
failable @objc initializer cannot also be throwing. However,
Objective-C selector computation is broken.
Swift SVN r27292
Synthesize implicit @availability attributes to make sure that a synthesized
materializeForSet accessor is available enough to access the underlying storage and its
getter and setter.
These synthesized attributes could trigger redundant diagnostics when a subclass gives
overriding getters or setters non-contravariant availability. We detect when this
happens and suppress the redundant diagnostics.
This commit also improves availability diagnostics in synthesized code. We now respect
synthesized @availability annotations on containing DeclContexts when determining the
potential OS versions that could be executed at invalid SourceLocations.
Swift SVN r27002
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
exposed keyword arguments into the TuplePatterns labels.
Switch tuple conversion to use tuplepattern labels instead of parameter labels.
Swift SVN r26861
When synthesizing a designated initializer override, we now ensure that the synthesized
initializer has the same availability as the initializer it is overriding.
Swift SVN r26732
Remove the semantic restrictions that prohibited extensions of
protocol types, and start making some systematic changes so that
protocol extensions start to make sense:
- Replace a lot of occurrences of isa<ProtocolDecl> and
dyn_cast<ProtocolDecl> on DeclContexts to use the new
DeclContext::isProtocolOrProtocolExtensionContext(), where we want
that behavior to apply equally to protocols and protocol extensions.
- Eliminate ProtocolDecl::getSelf() in favor of
DeclContext::getProtocolSelf(), which produces the appropriate
generic type parameter for the 'Self' of a protocol or protocol
extension. Update all of the callers of ProtocolDecl::getSelf()
appropriately.
- Update extension validation to appropriately form generic
parameter lists for protocol extensions.
- Methods in protocol extensions always use the witnesscc calling
convention.
At this point, we can type check and SILGen very basic definitions of
protocol extensions with methods that can call protocol requirements,
generic free functions, and other methods within the same protocol
extension.
Regresses four compiler crashers but improves three compiler
crashers... we'll call that "progress"; the four regressions all hit
the same assertion in the constraint system that will likely be
addressed as protocol extensions starts working.
Swift SVN r26579
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
Previously, a multi-pattern var/let decl like:
var x = 4, y = 17
would produce two pattern binding decls (one for x=4 one for y=17). This is convenient
in some ways, but is bad for source reproducibility from the ASTs (see, e.g. the improvements
in test/IDE/structure.swift and test/decl/inherit/initializer.swift).
The hardest part of this change was to get parseDeclVar to set up the AST in a way
compatible with our existing assumptions. I ended up with an approach that forms PBDs in
more erroneous cases than before. One downside of this is that we now produce a spurious
"type annotation missing in pattern"
diagnostic in some cases. I'll take care of that in a follow-on patch.
Swift SVN r26224
- Rename getParentPattern() -> getParentPatternBinding(), since
it returns the pattern binding, not the pattern.
- Introduce new getParentPattern()/getParentInitializer() methods,
covering the most common uses of getParentPatternBinding().
NFC.
Swift SVN r26175
This changes 'if let' conditions to take general refutable patterns, instead of
taking a irrefutable pattern and implicitly matching against an optional.
Where before you might have written:
if let x = foo() {
you now need to write:
if let x? = foo() {
The upshot of this is that you can write anything in an 'if let' that you can
write in a 'case let' in a switch statement, which is pretty general.
To aid with migration, this special cases certain really common patterns like
the above (and any other irrefutable cases, like "if let (a,b) = foo()", and
tells you where to insert the ?. It also special cases type annotations like
"if let x : AnyObject = " since they are no longer allowed.
For transitional purposes, I have intentionally downgraded the most common
diagnostic into a warning instead of an error. This means that you'll get:
t.swift:26:10: warning: condition requires a refutable pattern match; did you mean to match an optional?
if let a = f() {
^
?
I think this is important to stage in, because this is a pretty significant
source breaking change and not everyone internally may want to deal with it
at the same time. I filed 20166013 to remember to upgrade this to an error.
In addition to being a nice user feature, this is a nice cleanup of the guts
of the compiler, since it eliminates the "isConditional()" bit from
PatternBindingDecl, along with the special case logic in the compiler to handle
it (which variously added and removed Optional around these things).
Swift SVN r26150
Corrected several places where compiler generated AST nodes were not properly
marked as implicit.
For interpolated strings also fixed string segment locations and made sure
the first and last segments are preserved in AST even if they are empty.
Swift SVN r25983
This is a better fix for rdar://problem/19941580: by providing trivial
accessors for all static properties, we have them there for any other
type checking that might need them, including the Objective-C selector
checking from the radar.
Swift SVN r25730
...rather than just assuming any initializer without a body that makes it
to SILGen is a memberwise initializer.
In the long term we want SILGen to stop handling these initializers, at
which point we can see if it makes sense to remove this body kind.
No intended functionality change.
Swift SVN r25723
Static members are never mutating, and having them be mutating in protocols
resulted in requirement mismatches.
rdar://problem/19887250
Swift SVN r25593
type checking any of the members of the type being analyzed, which leads to the
really exciting task of generating (e.g.) a memberwise initializer when you don't
know what the types of the members are.
Instead, synthesize these after the members are checked, which makes the code flow
much more like the other code synthesis stuff we do, and paves the way for future
improvements. NFC except one diagnostic in an error case (due to an order-of-checking
change).
This resolves <rdar://problem/16921173> implicit constructor synthesization works without validating the members of the type
Swift SVN r25545
If a non-static 'let' field in a struct has an initializer, its implicitly generated
memberwise initializer should not override that. Handle this by having the memberwise initializer
and default initializer use the initial value of the property instead of an argument to the init.
This would have been a lot easier if sema was synthesizing the ctor bodies instead of SILGen,
but here it is. The missing case is narrow (let (x,y) = (1,2)) and for now we just disable
implicit synthesization of the incorrect case.
Swift SVN r25424
Expose static stored properties in @objc classes as trivial class
methods.
static let i: T => +(T)i
static var i: T => +(T)i and +(void)setI:
static var k T { get set } => No change.
Fixes rdar://problem/19784053
Swift SVN r25152
The materializeForSet accessor for a `dynamic` property needs to dynamically invoke the getter and setter of the property in order to allow for runtime modification, so it doesn't need to be dynamically dispatched itself. If the property came from an imported ObjC class, then we can't dynamically dispatch it without polluting the selector namespace. Introduce a new 'ForcedStaticDispatch' bit and set it in order to force `dynamic` materializeForSet accessors to be statically dispatched. (They can't be `final` because it's legal to override a dynamic property.) If the property came from ObjC, register materializeForSet as an external declaration so it gets generated by SIL. Fixes rdar://problem/18706056.
Swift SVN r24930
Semantically, a dynamic property must always be dispatched in case it gets replaced at runtime, and an @NSManaged property may not have static accessors at all. Use ordinary access to the computed property accessors in materializeForSet when a property is dynamic or ObjC-originated. More rdar://problem/18706056.
There's still a problem--we try to vtable-dispatch materializeForSet, which is redundant for native classes, but impossible for imported ObjC classes. We should suppress this, but trying to make materializeForSet "final" breaks subclassing if the property is overridden.
This time, update test/SILGen/objc_properties.swift to avoid a false negative test failure.
Swift SVN r24888
