Implicit accessors are sometimes transparent for performance reasons.
Previously this was done in Sema by maybeMarkTransparent(), which would
add a TransparentAttr. Replace this with a request.
Accessors logically belong to their storage and can be synthesized
on the fly, so removing them from the members list eliminates one
source of mutability (but doesn't eliminate it; there are also
witnesses for derived conformances, and implicit constructors).
Since a few ASTWalker implementations break in non-trivial ways when
the traversal is changed to visit accessors as children of the storage
rather than peers, I hacked up the ASTWalker to optionally preserve
the old traversal order for now. This is ugly and needs to be cleaned up,
but I want to avoid breaking _too_ much with this commit.
We want to compute the former independently of the latter.
It's only 16 bits so storing it inside the Decl is fine;
it also allows us to eliminate the 'compact' representation
where an AbstractStorageDecl without an accessor record is
assumed to be stored.
Instead of requiring that function body synthesizers will always call
setBody(), which is annoyingly stateful, have function body synthesizers
always return the synthesized brace statement along with a bit that
indicates whether the body was already type-checked. This takes us a
step closer to centralizing the mutation of the body of a function.
Commit e0bba70 added a default implementation, however this is wrong
for non-imported types.
Instead, synthesize the body as before. Since this is one of the few
derived methods that can appear on an imported type, make sure to
build fully type-checked AST.
Fixes <rdar://problem/51322302>.
If a struct/enum cannot have Equatable/Hashable conformance automatically synthesized because a member's type is not Equatable/Hashable, add a note to the existing 'does not conform' diagnostic pointing out the type that blocked synthesis.
This is a step in the direction of fixing the fallthrough bug. Specifically, in
this commit I give case stmts a set of var decls for the bodies of the case
statement. I have not wired them up to anything except the var decl
list/typechecking.
rdar://47467128
SE-206 deprecated hashValue as a protocol requirement. We should gently encourage people to migrate to hash(into:), for its more secure, easier and faster hashing.
Emit a compiler warning whenever hashValue has an explicit implementation, but hash(into:) doesn’t.
* [AST] Remove stored TypeLoc from TypedPattern
TypedPattern was only using this TypeLoc as a means to a TypeRepr, which
caused it to store the pattern type twice (through the superclass and through
the TypeLoc itself.)
This also fixes a bug where deserializing a TypedPattern doesn't store
the type correctly and generally cleans up TypedPattern initialization.
Resolves rdar://44144435
* Address review comments
Parsed declarations would create an untyped 'self' parameter;
synthesized, imported and deserialized declarations would get a
typed one.
In reality the type, if any, depends completely on the properties
of the function in question, so we can just lazily create the
'self' parameter when needed.
If the function already has a type, we give it a type right there;
otherwise, we check if a 'self' was already created when we
compute a function's type and set the type of 'self' then.
Use the usual bag of tricks to eliminating dependence on the
TypeChecker instance: static functions, LazyResolver callbacks, and
emitting diagnostics on decls/ASTContext.
- getAsDeclOrDeclExtensionContext -> getAsDecl
This is basically the same as a dyn_cast, so it should use a 'getAs'
name like TypeBase does.
- getAsNominalTypeOrNominalTypeExtensionContext -> getSelfNominalTypeDecl
- getAsClassOrClassExtensionContext -> getSelfClassDecl
- getAsEnumOrEnumExtensionContext -> getSelfEnumDecl
- getAsStructOrStructExtensionContext -> getSelfStructDecl
- getAsProtocolOrProtocolExtensionContext -> getSelfProtocolDecl
- getAsTypeOrTypeExtensionContext -> getSelfTypeDecl (private)
These do /not/ return some form of 'this'; instead, they get the
extended types when 'this' is an extension. They started off life with
'is' names, which makes sense, but changed to this at some point. The
names I went with match up with getSelfInterfaceType and
getSelfTypeInContext, even though strictly speaking they're closer to
what getDeclaredInterfaceType does. But it didn't seem right to claim
that an extension "declares" the ClassDecl here.
- getAsProtocolExtensionContext -> getExtendedProtocolDecl
Like the above, this didn't return the ExtensionDecl; it returned its
extended type.
This entire commit is a mechanical change: find-and-replace, followed
by manual reformatted but no code changes.
(or __derived_struct_equals)
We want to make sure that if someone replaces the synthesized
implementation with a handwritten one, it doesn't change the ABI.
The simplest way to do that is to not use this clever workaround.
https://bugs.swift.org/browse/SR-8294
Existing comment references the old way to do the comparison with a
state variable. Updated comment covers how the function works and
matches up the parameter names too.
There are two general constructor forms here:
- One took the number of parameter lists, to be filled in later.
Now, this takes a boolean indicating if there is an implicit
'self'.
- The other one took the actual parameter lists and filled them
in right away. This now takes a separate 'self' ParamDecl and
ParameterList.
Instead of storing the number of parameter lists, an
AbstractFunctionDecl now only needs to store if there is a 'self'
or not.
I've updated most places that construct AbstractFunctionDecls to
properly use these new forms. In the ClangImporter, there is
more code that remains to be untangled, so we continue to build
multiple ParameterLists and unpack them into a ParamDecl and
ParameterList at the last minute.
Because people put all sorts of nonsense into @objc enums (most
reasonably, "private cases", which represent valid values that are not
API), the Swift-synthesized implementation of 'hash(into:)' needs to
not expect a switch statement to be exhaustive. And since
Swift-defined @objc enums are supposed to behave enough like C-defined
enums, they should at least handle simple method calls with an invalid
raw value, which means that 'rawValue' likewise should not use a
switch.
This patch provides alternate implementations that look like this:
extension ImportedEnum {
public var rawValue: Int {
return unsafeBitCast(self, to: Int.self)
}
public func hash(into hasher: inout Hasher) {
hasher.combine(self.rawValue)
}
}
rdar://problem/41913284
