When member lookup completely fails and when CSDiags is the one performing
the lookup, reissue another lookup that ignores access control. This allows
it to find inaccessible members and diagnose them as such, instead of pretending
we have no idea what the user wants. We now produce an error message like this:
main.swift:1:6: error: 'foo' is inaccessible due to 'private' protection level
C().foo()
^
test.swift:1:35: note: 'foo' declared here
internal class C { private func foo() {} }
^
instead of:
main.swift:1:2: error: value of type 'C' has no member 'foo'
C().foo()
^~~ ~~~
At some point I want to propose a revised model for exports, but for now
just mark that support for '@exported' is still experimental and subject
to change. (Thanks, Max.)
Before:
error: cannot import module being compiled
After:
warning: file 'foo.swift' is part of module 'Foo'; ignoring import
rdar://problem/22635888
Swift SVN r31995
Also, suggest "xcrun swiftc" instead of "xcrun swift" on OS X, since
"swift" already infers SDKs and we shouldn't get into this situation.
(We shouldn't get into it on non-OS-X either thanks to the previous
commit, but just in case.)
rdar://problem/22440615
Swift SVN r31535
The case where this comes up is when people name their app and framework
targets the same thing, or when they've renamed their test target module
in an attempt to avoid issues with NSClassFromString and differing
runtime names. We currently do various wrong things when this happens,
so just emit an error instead.
I left a hole for our overlays, which use '@exported import <the-current-module>'
to get at their Clang modules. The previous commit means this can be
replaced by -import-underlying-module, but that doesn't help our tests,
which use -enable-source-import for their overlays. Which we should stop doing.
rdar://problem/21254367
Swift SVN r29440
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
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
