This includes proper rules for function overloads (i.e. shadowing by type)
and allowing type lookup to find a type even if it has the same name as
a non-type.
lookupVisibleDecls does not use this behavior yet.
Swift SVN r7016
This required a general reworking of the algorithm for qualified name lookup.
Originally, qualified lookup only applied to a module -- not to its exports.
This meant that "Cocoa.NSWindow" would fail, so that was changed to grovel
through all exported modules looking for decls if the top-level module didn't
provide any.
Now, we actually do a breadth-based search, stopping at each level if decls
are provided for a given name. We also now prefer scoped imports to unscoped
imports, so "import abcde" and "import struct asdf.D" will result in a
(qualified) reference to 'D' being unambiguous.
Not working yet:
- Shadowing for unqualified lookup.
- Shadowing by types, so that overloads from this module can merge with
overloads from its exports.
Swift SVN r7014
Before this change, DeclContext of all imported decls was set to the first
imported module.
No tests now, will be tested by future code completion commits.
Swift SVN r6949
The current implementation of dealloc_stack in IR-gen is a
no-op, but that's very much wrong for types with non-trivial
local allocation requirements, e.g. archetypes. So we need
to be able to do non-trivial code here. However, that means
modeling both the buffer pointer and the allocated address
in SIL.
To make this more type-safe, introduce a SIL-specific
'[local_storage] T' type that represents the required
allocation for locally storing a T. alloc_stack now returns
one of those in additon to a *T, and dealloc_stack expects
the former.
IR-gen still implements dealloc_stack as a no-op, but
that's now easy to fix.
Swift SVN r6937
When we're diagnosing an error during the initialization of a
parameter from an argument, point at the actual parameter (if we can
find it) or at least the function (if we can't) where the call
failed. Baby steps:
t2.swift:3:4: error: '(x : Int, y : Int)' is not a subtype of 'Int'
f3(f3b)
^
t2.swift:1:9: note: in initialization of parameter 'x'
func f3(x : (x : Int, y : Int) -> ()) {}
^
Swift SVN r6924
Since we only print a single line, there's no point in including the
open-brace at the end. Moreover, modules are /supposed/ to be opaque.
The user shouldn't be thinking about how any adapter functions work,
either.
On the other hand, if we're looking at a non-top-level decl, we want to
see it as if it were in context, so in that case we can be more "source-y".
Swift SVN r6919
Again, the import kind rules are:
- 'import KIND' can import any decl whose introducer is KIND.
- 'import typealias' can also import a struct, class, or union.
- Conversely, 'import KIND' can import a typealias for a decl whose
introducer is KIND.
- Only functions can be overloaded; anything else counts as an ambiguous
import and is an error.
- If an import statement only imports a single decl, but the user got the
kind wrong, we can issue a fix-it for the kind.
We don't have source locations or synthetic source for declarations yet,
so there are no notes about what's /causing/ the ambiguities. Tracked by
<rdar://problem/14650883>
Swift SVN r6917
capture analysis is gone. This functionality is subsumed by SIL passes,
which turn boxes into stack allocations.
One minor detail of this is that dealloc_ref isn't implemented yet in IRGen
(rdar://14648382) and SILGen produces it for destructors (e.g. see
test/SILGen/lifetime.swift). To unblock progress, I just removed the
llvm_unreachable in IRGen.
Swift SVN r6890
Build a switch_union instruction over all the matched union elements, and check for exhaustiveness to see if we need to emit a default branch either for subsequent matches or to fall off the end and emit unreachable if we run out of cases.
Swift SVN r6870
Factor the ProtocolConformance class into a small hierarchy of
protocol conformances:
- "normal" conformance, which provides a complete mapping for the
explicit conformance of a nominal type (which may be generic) to a
protocol;
- "specialized" conformance, which specializes a generic
conformance by applying a set of substitutions; and
- "inherited" conformance, which projects the conformance from a
superclass to a conformance for a subclass.
In this scheme "normal" conformances are fairly heavyweight, because
they provide a complete mapping. Normal conformances are unique,
because they're associated with explicit conformance declarations
(which cannot be repeated within a module; checking is TBD). Thus, IR
generation will eventually emit them as strong symbols.
"Specialized" and "inherited" conformances occur when we're dealing
with generic specializations or subclasses. They project most of their
members through to some underlying conformance, eventually landing at
a "normal" conformance. ASTContext is responsible for uniquing these
conformances when it sees them. The IR generation model for
specialized conformances will involve runtime specialization of the
underlying witness table; inherited conformances are probably no-ops
from the IR generation perspective.
Aside from being the right thing to do, having small, uniqued
conformances for the specialization and inheritance cases is good for
compile-time performance and memory usage. We're not really taking
advantage of this everywhere we could, yet.
This change uncovered a few existing issues (one known, one not
known), particularly because we're projecting inherited conformances
rather than building new conformances:
- <rdar://problem/14620454>: protocol witnesses to methods of
classes need to perform dynamic dispatch. See the
test/Interpreter/typeof.swift test for an example.
- <rdar://problem/14637688>: comparing NSString and String with ==
fails, because they are inter-convertible. I suspect we were missing
some protocol conformances previously, and therefore accepting this
obviously-invalid code.
Swift SVN r6865
This is the Swift equivalent of allowing Cocoa.NSWindow to find
AppKit.NSWindow (or AppKit.NSWindow.NSWindow, really). Some of these
error messages could be improved, but the basic semantics are correct.
Swift SVN r6855
Note that the import kind is not checked yet; this is effectively our old
behavior for "import swift.print".
Infrastructure: move Module::forAllVisibleModules out-of-line, and add
makeStackLambda to STLExtras for using a non-escaping lambda with
std::function.
Swift SVN r6852
This makes it very clean to reason about which part should be used
to find a module to load, and which part should be used to filter
lookup within that module.
This breaks the old "import swift.print" syntax in favor of the new
"import func swift.print", but the new syntax is currently ignored.
Swift SVN r6849
Also, update LangRef.
Note that an explicit "import module" has been left out for now, since
it's not strictly necessary and "module" isn't a keyword yet.
Swift SVN r6786
We haven't fully updated references to union cases, and enums still are not
their own thing yet, but "oneof" is gone. Long live "union"!
Swift SVN r6783
When we notice that a type implicitly conforms to a protocol but is
not explicitly stated to do so, note this and provide a Fix-It
attaching the conformance to a declaration within the translation
unit, e.g.,
t.swift:28:16: error: type 'S1' does not explicitly conform to protocol 'P'
var p1 : P = S1()
^
t.swift:8:8: note: introduce explicit conformance to protocol 'P'
struct S1 : Q {
^
, P
Swift SVN r6760
Now that we have true serialized modules, the standard library can import
the Builtin module without any special direction (beyond -parse-stdlib),
and anyone can include those modules without special direction.
Swift SVN r6752
A SuperRefExpr semantically includes an upcast, and coercing it to a deeper subclass by wrapping it in a DerivedToBaseExpr is redundant and confuses SILGen. Instead, update the type of the SuperRefExpr directly before loading from it. Fixes <rdar://problem/14581294>.
Swift SVN r6720
Detect duplicate and multiple inheritance, clean up diagnostics, and
unify the code that checks the types in the inheritance clause with
the code that sets the superclass and protocol lists.
Swift SVN r6706
This iterates over a module's exports, transitively, in an unspecified
but deterministic order. This is useful for any sort of lookup and for
managing transitive inclusion. It also allows us to remove the hack in
Sema for loading a Clang module's adapter module, and just rely on the
previous commit.
Swift SVN r6699
This makes it very clear who is depending on special behavior at the
module level. Doing isa<ClangModule> now requires a header import; anything
more requires actually linking against the ClangImporter library.
If the current source file really can't import ClangModule.h, it can
still fall back to checking against the DeclContext's getContextKind()
(and indeed AST currently does in a few places).
Swift SVN r6695
Standardize on the more-common "superclass" and "subclass" terminology
throughout the compiler, rather than the odd mix of base/derived and
super/sub.
Also, have ClassDecl only store the Type of the superclass. Location
information will be part of the inheritance clause for parsed classes.
Swift SVN r6687
The 'inherited' type list of a declaration represents the parsed for
of the inheritance clause, which is now not serialized. The semantic
informance exists in the superclass (when present) and list of
protocols. Future refactoring of the 'inherited' list will make this
more clear.
Swift SVN r6686
Previously, we only tracked the mapping from associated types to their
type witnesses. Now, also track the protocol conformances for each of
the requirements placed on the associated types.
Swift SVN r6655
-Introduce PersistentParserState to represent state persistent among multiple parsing passes.
The advantage is that PersistentParserState is independent of a particular Parser or Lexer object.
-Use PersistentParserState to keep information about delayed function body parsing and eliminate parser-specific
state from the AST (ParserTokenRange).
-Introduce DelayedParsingCallbacks to abstract out of the parser the logic about which functions should be delayed
or skipped.
Many thanks to Dmitri for his valuable feedback!
Swift SVN r6580
This involved threading it through ModuleLoader, as with all the other
module-generic callbacks. I plan to collapse a bit of the chaining, but
unfortunately not that much.
This brings back the CodeCompletion tests.
Swift SVN r6527
