Rather than automatically re-exporting or not re-exporting every import in
a TranslationUnit, we'll eventually want to control which imports are local
(most of them) and which imports are shared with eventual module loaders.
It's probably not worth implementing this for TranslationUnit, but
LoadedModule can certainly do something here.
Currently, a LoadedModule is even more permissive than a TranslationUnit:
all imports are re-exported. We can lock down on this once we have a
re-export syntax.
Swift SVN r6523
...and use it for shadowed modules (e.g. the Clang module "Foundation"
referenced by the Swift module "Foundation"), so that we can actually
find "NSString" when building AppKit.
Additionally, record shadowed modules as dependencies, so that they can
be loaded when the adapter module is loaded.
Swift SVN r6522
importing them
Because going through the import for every code completion request is slow,
Clang code completion results are cached in the CodeCompletionContext. The
cache needs to be invalidated whenever a new Clang module is loaded. In order
to implement this, ModuleLoadListener class was added.
Swift SVN r6505
This change also exposes and fixes a bug where we would improperly filter
shadowed declarations. removeShadowedDecls() assumed that all decls had the
same name, but when it is used from lookupVisibleDecls(), this is not true.
Thus, we group decls not only by signature, but also by name.
Swift SVN r6460
Restore ProtocolType to its proper always-canonical-typedness, now
that the type checker isn't conflating "canonical" with "no
interesting conversions".
Swift SVN r6451
Removes the boolean IsTypeLookup and OnlyInstanceMembers, which were totally
misleading.
This fixes some bugs in lookupVisibleDecls, which allows us to remove
workarounds in code completion, that were not correct in some corner cases.
Now we also code complete references to instance functions in static contexts,
but code completion results in this case state the type of the resulting object
incorrectly.
Swift SVN r6396
This is a temporary hack until we properly make these carry
their own generic parameters.
This removes the last valid way to get UnboundGenericTypes in
a checked program.
Swift SVN r6373
for protocols when code completing outside the protocol's DeclContext on a
protocol's instance
'This' is obviously not allowed, but references to nested typealiases are
sometimes allowed on protocol instances, but only sometimes (filed
rdar://14489286). Just don't display such code completion results for now.
Swift SVN r6372
the containing DeclContext
Fixes a few FIXMEs in code completion where we were providing results that
refer to generic arguments outside of their scope.
Swift SVN r6370
This eliminates the odd separate pass over default arguments, as well
as the isFirstPass distinction for type checking patterns,
centralizing default argument checking. It actually regresses us
slightly (see <rdar://problem/14488311>) due to name binding happening
too early (and, therefore, in the wrong context). This will be fixed
by moving name binding into constraint generation.
Swift SVN r6368
is documented: look up members of a type that are visible from a specific
module. It does not matter much now, but when we have access control, it will.
Before this change, lookupVisibleDecls() tried to guess the *defining* module
of the type, and gave up if it could not. It forced us to duplicate some
lookup logic for some types (archetypes and protocol compositions). Also add a
test that lookup finds members of archetype's superclass, which the original
(duplicated) code did not handle.
Swift SVN r6363
- Add the attribute to AnyFunctionType::ExtInfo.
- Propagate the attributes from DeclAttributes to AnyFunctionType for
FuncDecls in TypeCheckDecl.cpp.
- Make sure the new attribute is serialized.
The main missing pieces are checking the applicability of the type attributes
on the FuncDecl and teaching typechecker about conversions on types with
noreturn.
Swift SVN r6359
Elements of a tuple type now know if there is a default argument, and
what kind of default argument it is (callee side, __FILE__, __LINE__,
__COLUMN__), but they don't have an actual expression. There are a
number of cleanups this enables that will follow.
Note that the serialization support is as-yet-untested.
Swift SVN r6351
There is a bunch of copy-and-paste here from the tuple-shuffle
code. The expected trajectory is that ScalarToTupleExpr will grow into
a general TupleConversionExpr, obviating the need for TupleShuffleExpr
entirely and eliminating the redundancy.
Swift SVN r6347
need to unwrap the type sugar.
This was uncovered by the removal of IdentifierType and removal of
getCanonicalType() in code completion, which was working around
lookupVisibleDecls() not working for IdentifierTypes.
Swift SVN r6332
-Refactor Parser to stop creating types
-Refactor TypeChecker to create types by resolving TypeReprs.
-Remove "validation" bit from the type system.
We don't need to "validate" every type that gets created but there's still a validation bit in TypeLoc,
necessary because of generic substitutions.
Swift SVN r6326
At some point this will change because of re-exported modules, but for now
just don't crash when performing unqualified lookup on a loaded module.
Also, auto-load our adapter libraries for loaded modules, not just TUs.
Include "POSIX" in this list. (We really need autolinking.)
Swift SVN r6303
Teach TuplePatternElt to keep track of the kind of the default
argument: none, normal (provided by calling into the appropriate
callee generator), __FILE__, __LINE__, or __COLUMN__. For the latter
three cases, the type checker forms the appropriate argument as part
of the call.
The actual default argument expression will only be held in the tuple
pattern element when we've parsed it; it won't be serialized or
deserialized, because only the defining module cares. This is a step
toward eliminate the initialization expression from tuple types.
The extension to TupleShuffleExpr is a hack, which will also be
replicated in ScalarToTupleExpr, until we finally rework the
representation of TupleShuffleExpr (<rdar://problem/12340004>).
Swift SVN r6299
Refactored the function calling conventions,"thin" attribute, and other extra function info bits to be stored inside the TypeBits. The isAutoClosure and IsBlock bits are also pulled up into AnyFunctionType.
This should make it easier to construct and propagate the attributes. Using ExtInfo struct to simplify the FunctionType is coming up next.
Swift SVN r6284
Eventually TypeLocs coming from the Parser will contain only a TypeRepr and the TypeChecker will resolve and add the type.
Passing a TypeLoc to a diagnostic means "print as user written" (even before typechecking)
and if there is no TypeRepr (e.g. due to a TypeLoc coming from a module without location info) print the type.
Swift SVN r6280
If we see '.Foo' or '.Foo(...)' in a case, resolve it as a OneOfElementPattern with element to be determined at type-checking time. If we see 'A.B' or 'A.B(...)', try to resolve 'A.B' as a qualified reference to a OneOfElementDecl, and resolve the expression as a OneOfElementPattern referencing that decl if we find one. During type-checking, resolve the element decl for unresolved OneOfElementPatterns, then match the subpattern to the type of the element's associated data (or void if it has none).
A few cases don't yet work right that ought to:
- Qualified references to generic oneof cases with generic arguments elided, e.g. 'case Optional.None:'
- Qualified references to generic oneof cases through a module, e.g. 'case swift.Optional<Int>.None:'
Swift SVN r6278
The semantics of varargs (only for the last element) make it more appropriate as a property of the TuplePattern.
Also free the Parser from needing to construct synthetic types (ArraySlice for type of vararg element) to
accommodate the TypeChecker and move the logic to the TypeChecker. This will be more beneficial when the parser stops
creating types in general.
Swift SVN r6271
Give oneof bodies syntax consistent with other NominalTypes. Give oneof elements first-class declaration syntax using the 'case' introducer, as suggested by Jordan. Oneofs can contain 'case' decls, functions, properties, and constructors, but not physical ivars. Non-oneof scopes cannot contain 'case' decls. Add some QoI to the oneof 'case' parser to also parse and complain about things that resemble switch 'case' labels inside decl contexts.
Swift SVN r6211
