getImportedModules is the canonical way to get imports, whether private,
public, or both. This is especially true now that we have more flags
for SourceFile imports that really shouldn't be consumed by anyone
outside of SourceFile.
In this same vein, provide addImports instead of setImports, since imports
are always additive.
No visible functionality change.
Swift SVN r26634
...which allows "@testable import" to work with modules not compiled for
testing. This isn't generally safe, but should be fine for clients like
SourceKit which just need to have the API available and might not be able
to properly rebuild the original target for testing.
We may revisit this in the future.
Swift SVN r26629
LLDB has been setting 'Playground' for their REPL mode too to get some of
these behaviors, but that's not something we want to do long-term, and it's
already been subtly wrong in a few cases. Now 'Playground' really does mean
playgrounds, and 'DebuggerSupport' means REPL /or/ LLDB expression parser
mode.
rdar://problem/18338200
Swift SVN r22030
For now, also check that -playground is off; once <rdar://problem/18090611>
is in we can drop this check and treat them as mostly orthogonal options.
Part of <rdar://problem/17994094>
Swift SVN r21385
We don't want typos in import statements to take down the whole REPL, but we
/do/ want the REPL to be honoring fatal errors that effectively take down the
ASTContext.
This doesn't (yet) apply to the real LLDB REPL, which does not use
SourceFileKind::REPL for its input. The right option to test there is
LangOpts.DebuggerSupport, but that's currently being set for Playgrounds as
well. I've filed <rdar://problem/18090611> for LLDB to adjust their input.
Part of <rdar://problem/17994094>
Swift SVN r21383
"import func Darwin.C.math.hypot" will now work to just import "hypot".
(Since 'Darwin.C.math' is an implicit submodule of 'Darwin',
"import func Darwin.hypot" also works. That's okay.)
<rdar://problem/17272311>
Swift SVN r20356
Specifically, handle them by also importing the top-level module. This is
unfortunate, but at least lets people /access/ things in explicit submodules,
even if it doesn't let them limit their import to a specific submodule.
(swift) import OpenGL.GL3
(swift) glGetString
// r0 : (GLenum) -> ConstUnsafePointer<GLubyte> = (Function)
(swift) OpenGL.glGetString
// r1 : (GLenum) -> ConstUnsafePointer<GLubyte> = (Function)
One unfortunate side effect of having a single Clang ASTContext is that if
one Swift module imports a Clang submodule, every Swift module can now see
it. That means /mixing/ incompatible submodules, such as OpenGL.GL and
OpenGL.GL3, still won't work. Filed <rdar://problem/17756745> for that.
<rdar://problem/13140302>
Swift SVN r20288
While this should be a pointless performance tweak along a path where
we don't care about performance, it actually matters because we
occasionally end up copying SmallStrings or std::strings, then taking
StringRefs to the copies and holding on to them. This was manifesting
as occasional corruption in keyword-argument diagnostics.
Swift SVN r17811
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
