Even though declarations end up in the top-level module, this can still
/expose/ them if the submodule is explicit. I'll have to think more about
this.
This reverts r17656 / <rdar://problem/16818519>
Swift SVN r17668
..."resolveExternalDeclImplicitMembers".
Now that the ClangImporter has direct access to the type-checker (through
a LazyResolver), there's no reason to bounce through an obtusely generic
interface on ASTContext. Just call through directly to handle the implicit
members and conformances of external decls.
There's no actual functionality change here, though we can probably do
further cleanup in this area.
Swift SVN r15356
This reverts commit r14488, since we're demoting 'type' back to a plain old identifier.
We could consider reallowing 'type' as a contextual keyword here, but from talking to Jordan he was OK with just reverting this functionality.
Swift SVN r14931
Previously this was spelled "import typealias", and that spelling will
continue to be allowed (since someone may specifically be importing a
typealias and want that to match), but now that 'type' is a keyword,
"import type" is the right way to spell the generic "import any type"
scoped import.
Swift SVN r14488
LLDB creates variables that have types before name binding and type checking
actually occur, and this can bring in types from the Clang importer...which
then don't satisfy the constraints of a valid AST. Make sure we always get
a shot at checking these decls.
No test case, unfortunately, but LLDB should have one in their test suite
once this goes in.
<rdar://problem/15838120>
Swift SVN r12686
Thanks to the way we've set up our diagnostics engine, there's not actually
a reason for /everything/ to get rebuilt when /one/ diagnostic changes.
I've split them up into five categories for now: Parse, Sema, SIL, IRGen,
and Frontend, plus a set of "Common" diagnostics that are used in multiple
areas of the compiler. We can massage this later.
No functionality change, but should speed up compile times!
Swift SVN r12438
(swift) import Darwin
<REPL Input>:1:8: error: no such module 'Darwin'
import Darwin
^
<unknown>:0: note: did you forget to set an SDK using -sdk or SDKROOT?
This note does not fire if any SDK path is set, even an invalid one.
Swift SVN r12415
This completes the FileUnit refactoring. A module consists of multiple
FileUnits, which provide decls from various file-like sources. I say
"file-like" because the Builtin module is implemented with a single
BuiltinUnit, and imported Clang modules are just a single FileUnit source
within a module.
Most modules, therefore, contain a single file unit; only the main module
will contain multiple source files (and eventually partial AST files).
The term "translation unit" has been scrubbed from the project. To refer
to the context of declarations outside of any other declarations, use
"top-level" or "module scope". To refer to a .swift file or its DeclContext,
use "source file". To refer to a single unit of compilation, use "module",
since the model is that an entire module will be compiled with a single
driver call. (It will still be possible to compile a single source file
through the direct-to-frontend interface, but only in the context of the
whole module.)
Swift SVN r10837
I tried hard find all references to 'func' in documentation, comments and
diagnostics, but I am sure that I missed a few. If you find something, please
let me know.
rdar://15346654
Swift SVN r9886
Previously we would cache the results of operator lookup whether or not the
operator we found came from an imported module. Since different source files
can have different imports, it's not correct to automatically share operators
from imported modules with all files in the translation unit.
This still isn't fully correct; the current logic prefers operators from
local imports over operators implicitly available from other source files.
Swift SVN r9683
There is still plenty of fallout to get everything fully correct, but
right now we can build the standard library and run all the tests in
multiple-file mode.
Swift SVN r9673
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
Right now this is just an extra layer of indirection for the decls,
operators, and imports in a TU, but it's the first step towards compiling
multiple source files at once without pretending they're all in a single
file. This is important for the "implicit visibility" feature, where
declarations from other source files in the same module are accessible
from the file currently being compiled.
Swift SVN r9072
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
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
...instead of just those that are re-exported. This will be used for
autolinking (and probably few other places).
As part of this, we get two name changes:
(1) Module::getReexportedModules -> getImportedModules
(2) TranslationUnit::getImportedModules -> getImports
The latter doesn't just get modules-plus-access-paths; it also includes
whether or not the import is re-exported. Mainly, though, it just didn't
seem like a good idea to overload this name when the two functions aren't
really related.
No tests yet, will come with autolinking.
Swift SVN r7487
Previously, TypeAliasDecl was used for typealiases, generic
parameters, and assocaited types, which is hideous and the source of
much confusion. Factor the latter two out into their own decl nodes,
with a common abstract base for "type parameters", and push these
nodes throughout the frontend.
No real functionality change, but this is a step toward uniquing
polymorphic types, among other things.
Swift SVN r7345
We never really discussed this and it doesn't really buy us much. If we
want to have a compact way to import many things, it may not even end
up looking like this.
Swift SVN r7015
We can get to these transitively; we should only record what the TU
actually claims to reference.
It turns out that we were still relying on this to force the load of
adapter modules for Clang modules. For now, we just force that up front,
even though currently that also forces the creation of ClangModule
wrappers for all transitive includes.
No intended visible functionality change.
Swift SVN r7012
main.swift: error: ambiguous name 'A' in module 'letters'
import struct letters.A
abcde.A: note: found this candidate
struct A {}
aeiou.A: note: found this candidate
struct A {}
main.swift: 'B' was imported as 'var', but is a struct
import var letters.B
abcde.B: note: 'B' declared here
struct B {}
<rdar://problem/14650883>
Swift SVN r6918
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
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
Our diagnostic message says "no such module 'NAME'". However, if we tried
to import a submodule, the top-level module's name would be used for NAME
and the submodule part dropped. For now, just don't include the name if
importing a submodule.
Swift SVN r6851
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
