When we see an enum declaration in the Clang importer, look at its source location to see if it was produced as part of an NS_ENUM macro expansion. If so, take the 'Enum' route through the Clang importer and import it as a Swift enum. This will break things until we have end-to-end support for Clang-imported enums, so hide it behind an -import-ns-enum switch for now.
Swift SVN r9951
A single swift module can correspond to multiple Clang submodules. We need to
ask the underlying clang::Decl about the owning Clang module to get the most
precise answer.
Swift SVN r9859
Whatever kind of Swift decl we cons up for a Clang enum, add it to the externals list so we can pick it up and emit Swift metadata for it in IRGen. Fixes <rdar://problem/15242452>.
Swift SVN r9801
ASTContexts
This introduces swift::ide::CodeCompletionCache, which is a persistent code
completion result cache.
Right now REPL happens to use it (try importing Cocoa and doing code
completion), and the difference is noticeable. But completion in REPL is
still slow, because Cocoa goes through the AST Verifier on every completion
(for unknown reasons).
This commit does not implement cache invalidation yet, and it does not use
libcache to evict cache entries under memory pressure.
This commit also introduces two regressions:
- We get fewer Cocoa results that expected. Module::isModuleVisible in Clang
does not incorrectly reports that that ObjectiveC.NSObject submodule is not
visible from Cocoa.
- We are not implementing the decl hiding rules correctly. We used to rely on
visible decl lookup to do it for us, but now we have a different data structure
we have real decls from the current module and we have a text-only cache, so we
are forced to reimplement this part of name lookup in code completion.
Swift SVN r9633
NSDictionary's implementation of -objectForKeyedSubscript: takes an id
instead of 'id <NSCopying>' because a dictionary could in theory have non-
copyable keys. However, Swift requires the getter and setter for a subscript
operator to have the same type. Therefore, we unilaterally import the
getter as 'subscript(key : NSCopyingProto) { get }', and just rely on the
fact that the representation of 'id' and 'id <NSCopying>' is the same.
What doesn't change:
- objectForKey() still takes a plain 'id', in the rare cases that that is
useful.
- Looping over an NSDictionary still gives you (id, id) pairs, on the grounds
that if you actually want to do something with the key, it probably isn't
going to be copying it. Without this, doing something useful with the key
would require an explicit cast.
- If any other subscript indexes don't match up, the subscript is dropped
(r8636).
<rdar://problem/14397360>
Swift SVN r9424
If Foundation wasn't ever actually loaded into the ASTContext, type
lowering would fail to find the NSString-to-String conversion functions.
Fix this by only bridging NSString when a module named "Foundation" can
be loaded.
This still isn't very precise, since the bridging functions could still
be missing, but it at least avoids a user-triggerable error.
<rdar://problem/15027448>
Swift SVN r9380
of having a ton of ad-hoc bools in it. This allows us to consolidate a ton of
boilerplate, eliminating 250 lines of code:
17 files changed, 435 insertions(+), 662 deletions(-)
2) This eliminates the special case for weak and unowned attributes, which previously
didn't show up in Attr.def.
3) While we're at it, keep track of proper source locations for each attribute, and
use these to emit diagnostics pointing at the attribute in question instead of at
a funcdecl or the @ sign.
4) Fix axle attributes, which had vertex and fragment swapped.
Swift SVN r9263
Each one has a different kind of lookup cache anyway, and there's no real
reason to have them share storage at the cost of type-safety.
Swift SVN r9242
Now that we have a solid Optional-based story for dynamic casts, it's no longer needed, and can be expressed as '(x as T)!'. Future refinement of the 'as' syntax will deal with the unfortunate extra parens.
Swift SVN r9181
docs/Resilience.rst describes the notion of a resilience component:
if the current source file is in the same component as a module being
used, it can use fragile access for everything in the other module,
with the assumption that everything in a component will always be
recompiled together.
However, nothing is actually using this today, and the interface we
have is probably not what we'll want in 2.0, when we actually implement
resilience.
Swift SVN r9174
Pull the implicit 'Self' associated type out of the protocol and into
an implicitly-declared generic parameter list for the protocol. This
makes all of the methods of a protocol polymorphic, e.g., given
protocol P {
typealias Assoc
func getAssoc() -> Assoc
}
the type of P.getAssoc is:
<Self : P> (self : @inout P) -> () -> Self.Assoc
This directly expresses the notion that protocol methods are
polymorphic, even though 'Self' is always implicitly bound. It can be
used to simplify IRgen and some parts of the type checker, as well as
laying more of the groundwork for default definitions within
protocols as well as sundry other improvements to the generics
system.
There are a number of moving parts that needed to be updated in tandem
for this. In no particular order:
- Protocols always get an implicit generic parameter list, with a
single generic parameter 'Self' that conforms to the protocol itself.
- The 'Self' archetype type now knows which protocol it is
associated with (since we can no longer point it at the Self
associated type declaration).
- Protocol methods now get interface types (i.e., canonicalizable
dependent function types).
- The "all archetypes" list for a polymorphic function type does not
include the Self archetype nor its nested types, because they are
handled implicitly. This avoids the need to rework IRGen's handling
of archetypes for now.
- When (de-)serializing a XREF for a function type that has an
interface type, use the canonicalized interface type, which can be
meaningfully compared during deserialization (unlike the
PolymorphicFunctionType we'd otherwise be dealing with).
- Added a SIL-specific type attribute @sil_self, which extracts the
'Self' archetype of a protocol, because we can no longer refer to
the associated type "P.Self".
Swift SVN r9066
Semantic context describes the origin of the declaration and serves the same
purpose as opaque numeric "priority" in Clang -- to determine the most likely
completion.
This is the initial implementation. There are a few opportunities to bump the
priority of a certain decl by giving it SemanticContextKind::ExprSpecific
context that are not implemented yet.
Swift SVN r9052
Argument patterns create pseudo-named patterns, so make them implicit and ignore them when scanning for explicit source information.
Also make sure that the clang importer sets the HasSelectorStyleSignature bit appropriately.
Swift SVN r8803
The name used for name lookup of subscript operators is "__subscript",
but when looking into an Objective-C module we instead need to look
for methods with the subscripting selectors, e.g.,
objectAtIndexedSubscript:/objectForKeyedSubscript:. Do so, and make
sure that deserializing the method first still creates the subscript
declaration.
Fixes the majority of <rdar://problem/14656624>. We can subscript 'id' now.
Swift SVN r8700
These are the terms sent out in the proposal last week and described in
StoredAndComputedVariables.rst.
variable
anything declared with 'var'
member variable
a variable inside a nominal type (may be an instance variable or not)
property
another term for "member variable"
computed variable
a variable with a custom getter or setter
stored variable
a variable with backing storage; any non-computed variable
These terms pre-exist in SIL and IRGen, so I only attempted to solidify
their definitions. Other than the use of "field" for "tuple element",
none of these should be exposed to users.
field
a tuple element, or
the underlying storage for a stored variable in a struct or class
physical
describes an entity whose value can be accessed directly
logical
describes an entity whose value must be accessed through some accessor
Swift SVN r8698
Instead of synthesizing Swift code for the property and subscript
getters and setters we import from Objective-C, just create the
declarations and mark them as being Objective-C (foreign) entry
points. This means that we'll use the Objective-C entry points (via
objc_msgSend).
Swift SVN r8692
Instead, pass a LazyResolver down through name lookup, and type-check
things on demand. Most of the churn here is simply passing that extra
LazyResolver parameter through.
This doesn't actually work yet; the later commits will fix this.
Swift SVN r8643
The hack was that __attribute__((iboutletcollection(NSView))) can be
specified on a collection property to provide its value type, and the
ClangImporter library co-opted that as a way to import NSArray properties
as NSTypedArray<NSView> (or whatever), a layout-compatible Swift struct
type that provided a typed (runtime-checked) view of an NSArray. The
implementation of NSTypedArray was never completed, however; none of
our sample code is actually using it; and it turns out to be problematic
for some instances of lazy type checking (because NSTypedArray is defined
in Swift). Remove it; we'll revisit this later.
Swift SVN r8639
If the getter and setter have different index types, there's not much we can
do in Swift. It's better to not pretend to handle this (which currently leads
to a crash in SIL verification). Fortunately, this is likely very rare in
Objective-C, except for one special case:
We do plan to special-case this for NSDictionary, which has keys of type
'id' while NSMutableDictionary's setter uses 'id <NSCopying>'.
Swift SVN r8638
Introduce a bit in Expr to indicate whether the expression is implicit and decouple the implicitness
of an expression from whether it has a source location or not.
This allows implicit expressions to be able to point at the source location where they originated from.
It also allows decoupling the implicitness of a parent from its children, so for example, an implicit CallExpr
can have an explicit parameter value.
Swift SVN r8600
Iff an enum declares a raw type, its cases may declare raw values or else have them assigned to them implicitly by autoincrementing from zero, like in C. If the raw type is float-, string-, or char-literal-convertible, there is no autoincrement, and the raw values must all be explicit. The raw type is rejected if any cases have payloads.
We don't yet diagnose duplicate raw values. That'll come next. We also don't yet serialize or deserialize the raw values. We don't strictly need to do this, since the RawRepresentable protocol conformance will be exported from the module as API, but Jordan pointed out that, for fragile raw values, this would be good for documents/jump-to-definition purposes, so we have a plan for only serializing the literals without having to deal with fully general expression serialization.
Swift SVN r8545
Introduce an EnumCaseDecl for source fidelity to track the 'case' location and ordering of EnumElementDecls. Parse a comma-separated list of EnumElementDecls after a 'case' token.
Swift SVN r8509
