When we remove Sema's UsedConformances list, conformances to _BridgedStoredNSError
are checked from SILGen, where its too late to check function bodies of synthesized
functions.
We could solve this by adding a callback to type check a synthesized function's
body, but in fact all synthesized functions are rather trivial so it's better to
build their bodies fully type checked.
Start by building fully checked expressions for various accessors in ClangImporter.
Way back in Swift 1 I was trying to draw a distinction between
"overlays", separate libraries that added Swift content to an existing
Objective-C framework, and "the Swift part of a mixed-source
framework", even though they're implemented in almost exactly the same
way. "Adapter module" was the term that covered both of those. In
practice, however, no one knew what "adapter" meant. Bring an end to
this confusion by just using "overlay" within the compiler even for
the mixed-source framework case.
No intended functionality change.
This allows the conversion of the Windows `BOOL` type to be converted to
`Bool` implicitly. The implicit bridging allows for a more ergonomic
use of the native Windows APIs in Swift.
Due to the ambiguity between the Objective C `BOOL` and the Windows
`BOOL`, we must manually map the `BOOL` type to the appropriate type.
This required lifting the mapping entry for `ObjCBool` from the mapped
types XMACRO definition into the inline definition in the importer.
Take the opportunity to simplify the mapping code.
Adjust the standard library usage of the `BOOL` type which is now
eclipsed by the new `WindowsBool` type, preferring to use `Bool`
whenever possible.
Thanks to Jordan Rose for the suggestion to do this and a couple of
hints along the way.
* Moves the IsStatic flag from VarDecl to AbstractStorageDecl.
* Adds a StaticSubscriptKind to SubscriptDecl.
* Updates serialization for these changes.
* Updates SubscriptDecl constructor call sites for these changes.
Refactor the PlatformAvailability logic for determining
which Clang availability attributes are relevant when importing. The goal
is to separate the logic for attribute relevance for a given platform from
the logic to determine whether a deprecated attribute should be imported as
unavailable in Swift.
This also makes it possible for the "deprecated-as-unavailable" logic to
refer to the underlying Clang declaration, which is functionality that will
be used in a later commit.
This commit has no intended functional change.
Part of rdar://problem/48348822
The getLocStart API is deprecated and slated for removal from LLVM
very soon. Switch to use getBeginLoc instead. I did not see any uses
of the corresponding getLocEnd API.
This refactoring uses large portions of the already existing code for
x86_64 and s390 to implement AAPCS64 __VaListBuilder. The parts where
each implementation differ are the x86_64 header, and the order of the
general and vector registers.
The changes also addresses many of the request from the reviewers in
#20862 which were not addressed originally, like the reuse of the
already existing code, and the generalizations for the code to be useful
for platforms different than Linux (Android, for example).
Sema would directly check for the presence of the @objcMembers attribute,
and inherit it from the immediate superclass in validateDecl().
We don't want validateDecl() to have side effects like this and this was
already a problem, because it would not inherit the attribute transitively
in some cases.
Instead, add a ClassDecl::hasObjCMembers() method that walks over all
ancestors and caches the result.
<rdar://problem/46420252>
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
In #7530, NominalTypeDecl::lookupDirect() started returning TinyPtrVector instead of ArrayRef so that it wouldn’t be returning a pointer into a mutable data structure. Unfortunately, some callees assigned its return value into an ArrayRef; C++ happily converted the TinyPtrVector to an ArrayRef and then treated the TinyPtrVector as out-of-scope, so the ArrayRef would now point to an out-of-scope object. Oops.
This silences the instances of the warning from Visual Studio about not all
codepaths returning a value. This makes the output more readable and less
likely to lose useful warnings. NFC.
When we're marking a declaration as @objc and recording it in the
class and source-file lookup tables (for @objc collision detection),
don't cause a cycle by querying `getObjCSelector()`. This is somewhat
of a hack: a better long-term approach would be to move the recording
much later, and request'ify the name computation. That'll be follow-up
work.
* [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.
That is, if we encounter a property declaration, and a no-argument
method is visible, it's only a problem if there's not already a
property there. (Arguably this means that it's either not a problem at
all, or that we shouldn't be mirroring protocol methods onto classes
if there's a conflicting property, but this change doesn't attempt to
answer that.)
https://bugs.swift.org/browse/SR-8490
This makes it easier to grep for and eventually remove the
remaining usages.
It also allows you to write FunctionType::get({}, ...) to call the
ArrayRef overload empty parameter list, instead of picking the Type
overload and calling it with an empty Type() value.
While I"m at it, in a few places instead of renaming just clean up
usages where it was completely mechanical to do so.
- 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.
Note that these functions used to return a FunctionType; now, they
return the result type instead:
- importFunctionType()
- importMethodType()
- importAccessorMethodType()
The parameters were already being returned in the form of a ParameterList
of ParamDecls.
This actually has the effect of making the code simpler, because callers
would always take them apart and build new function types anyway.
Simple checks for the presence of a protocol in the “inherited” list should only
require a scan through that list + name lookup; use those facilities instead of
recursing through the type checker.
Introduce ExtensionDecl::getExtendedNominal() to provide the nominal
type declaration that the extension declaration extends. Move most
of the existing callers of the callers to getExtendedType() over to
getExtendedNominal(), because they don’t need the full type information.
ExtensionDecl::getExtendedNominal() is itself not very interesting yet,
because it depends on getExtendedType().
