llvm::Optional lives in "llvm/ADT/Optional.h". Like Clang, we can get
Optional in the 'swift' namespace by including "swift/Basic/LLVM.h".
We're now fully switched over to llvm::Optional!
Swift SVN r22477
This patch adds the beginning of building the type refinement context tree for
availability checking in Sema, guarded by by the
-enable-experimental-availability-checking option. This tree parallels the AST
but is much more sparse: we introduce a new TypeRefinementContext only when
needed. Each context refines the range of potential OS versions that could be
encountered at run time. For the moment, we only refine contexts for function
bodies. I will add refinement contexts for #os(...) in a later commit.
The AST is not directly connected to the TRC tree except at the SourceFile
level; when type checking, we use source locations to look up the TRC
corresponding to an AST element. For the moment, we emit a diagnostic when the
programmer references a potentially unavailable declaration. We will later
change this to treat the declaration as if it had optional type.
Swift SVN r22145
This works using the nominal's normal lookupDirect to gather decls from the
original declaration and all its extensions, then filters them by module and
private-discriminator. This does not yet do the right thing for extensions
because we don't include the extension's module in a member's mangling except
in very specific circumstances. In order to make this work in general we'll
have to start doing this more generally.
Part of rdar://problem/17632175
Swift SVN r21785
Now that there's just one entry point for discriminated lookup, there's not
really a need for this extra abstraction.
One thing still up in the air is unqualified lookup support for discriminator
preferences (for, say, breakpoint conditions), but we'll cross that bridge
when we come to it.
Part of rdar://problem/17632175
Swift SVN r21755
Since the primary purpose here is to go from a mangled name to a decl, and
discriminators are only valid in the context of a particular module, it
makes sense to make this an API on Module. Eventually this will also support
lookup into a type or its extensions, limited by module and discriminator.
Swift SVN r21754
This behaves like @UIApplicationMain, except for AppKit. Attach it to your NSApplicationDelegate, and an artificial "main" will be generated that invokes NSApplicationMain() for you. Implements rdar://problem/16904667.
Swift SVN r21697
This is useful both for caching purposes and for comparison of discriminators
(something the debugger will need to do when looking up a particular decl).
No observable functionality change.
Swift SVN r21610
Now we can test the mangling rules set up in the previous commit: include
the discriminator for the top-most 'private' decl, but not anything nested
within it.
Part of rdar://problem/17632175
Swift SVN r21599
We currently mangle private declarations exactly like public declarations,
which means that private entities with the same name and same type will
have the same symbol even if defined in separate files.
This commit introduces a new mangling production, private-decl-name, which
includes a discriminator string to identify the file a decl came from.
Actually producing a unique string has not yet been implemented, nor
serialization, nor lookup using such a discriminator.
Part of rdar://problem/17632175.
Swift SVN r21598
- Change the parser to accept "objc" without an @ sign as a contextual
keyword, including the dance to handle the general parenthesized case.
- Update all comments to refer to "objc" instead of "@objc".
- Update all diagnostics accordingly.
- Update all tests that fail due to the diagnostics change.
- Switch the stdlib to use the new syntax.
This does not switch all tests to use the new syntax, nor does it warn about
the old syntax yet. That will be forthcoming. Also, this needs a bit of
refactoring, which will be coming up.
Swift SVN r19555
(when -enable-access-control is used)
Note that this is currently circumvented when looking up requirements in a
protocol. We're not currently set up to pass along the DeclContext where a
protocol's requirements are requested /from/, so we're just relying on the
fact that the requirements have the same visibility as the protocol in 1.0.
Swift SVN r19355
If a source file contains the main class for its module, then implicitly emit a top_level_code that invokes UIApplicationMain with the name of the marked class.
Swift SVN r18088
This option implicitly imports the Clang module with the same name as the
module being built into every source file in the module being built.
This will be used for mixed-source framework targets to give Swift code the
same implicit visibility for Objective-C decls in the same module that it
already has for other Swift decls.
<rdar://problem/16701230>
Swift SVN r17053
The driver infers the filename from the module file by replacing the extension,
and passes the explicit path to the swiftdoc file to the frontend. But there
is no option in the driver to control emission of swiftdoc (it is always
emitted, and name is always inferred from the swiftmodule name).
The swiftdoc file consists of a single table that maps USRs to {brief comment,
raw comment}. In order to look up a comment for decl we generate the USR
first. We hope that the performance hit will not be that bad, because most
declarations come from Clang. The advantage of this design is that the
swiftdoc file is not locked to the swiftmodule file, and can be updated,
replaced, and even localized.
Swift SVN r14914
Make the name lookup interfaces all take DeclNames instead of identifiers, and update the lookup caches of the various file units to index their members by both compound name and simple name. Serialized modules are keyed by identifiers, so as a transitional hack, do simple name lookup then filter the results by compound name.
Swift SVN r14768
Sema was creating DerivedFileUnit on the fly, while something else is iterating
over FileUnits in the module. The fix is to create DerivedFileUnit in advance.
This change immediately uncovered a lot of code that assumed that the module
consists of a single FileUnit at certain conditions. This patch also fixes
that code (SourceKit patch is separate, not sending it).
The test change is because now operator == on NSObjects is correctly recognised
as coming from a system module.
rdar://16153700, rdar://16227621, possibly rdar://16049613
Swift SVN r14692
Teach name lookup to find complete object initializers in its
superclass when the current class overrides all of the subobject
initializers of its direct superclass.
Clean up the implicit declaration of constructors, so we don't rely on
callers in the type checker doing the right thing.
When we refer to a constructor within the type checker, always use the
type through which the constructor was found as the result of
construction, so that we can type-check uses of inherited complete
object initializers. Fixed a problem with the creation of
OpenExistentialExprs when the base object is a metatype.
The changes to the code completion tests are an improvement: we're
generating ExprSpecific completion results when referring to the
superclass initializer with the same signature as the initializer
we're in after "super.".
Swift SVN r14551
If an enum has no cases with payloads, make it implicitly Equatable and Hashable, and derive default implementations of '==' and 'hashValue'. Insert the derived '==' into module context wrapped in a new DerivedFileUnit kind, and arrange for it to be codegenned with the deriving EnumDecl by adding a 'DerivedOperatorDecls' array to NominalTypeDecls that gets visited at SILGen time.
Swift SVN r14471
Also, disallow creating Modules and FileUnits on the stack. They must always
live as long as the ASTContext.
<rdar://problem/15596964>
Swift SVN r13671
This re-applies r13401, reverted in r13404. This wasn't actually causing
problems, but got pulled along with r13400 (reverted in r13405).
Swift SVN r13452
Also, remove the mode that left the current module out of the callback.
That's easy enough to check for.
No functionality change yet, but groundwork for the next commit (as well
as some possible uses in LLDB).
Swift SVN r12616
location of variables at SIL generation time.
This patch introduces a SILDebuggerClient that
knows how to resolve the locations of variables
that are generated by the debugger. These
variables have a flag on them that only LLDB
sets.
Swift SVN r11230
Check for a REPL SourceFileKind along with Main before going the lazy initialization path. Also put response variables in the REPL SourceFile decl context so they are recognized as REPL variables and not lazily initialized. Handle PatternBindingDecls that appear under a script-mode SourceFile decl context but not a TopLevelCodeDecl context.
Swift SVN r11133
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
Now that everything is done in terms of FileUnits, we don't need LoadedModule
anymore, and now that FileUnits just use virtual dispatch, we don't need to
indirect through ModuleLoader to distinguish them.
This doesn't quite simplify as much as it could, because the next change is
going to combine TranslationUnit and Module.
Swift SVN r10836
Part of the FileUnit restructuring. A Clang module (whether from a framework
or a simple collection of headers) is now imported as a TranslationUnit
containing a single ClangModuleUnit.
One wrinkle in all this is that Swift very much wants to do searches on a
per-module basis, but Clang can only do lookups across the entire
TranslationUnit. Unless and until we get a better way to deal with this,
we're stuck with an inefficiency here. Previously, we used to hack around
this by ignoring the "per-module" bit and only performing one lookup into
all Clang modules, but that's not actually correct with respect to visibility.
Now, we're just taking the filtering hit for looking up a particular name,
and caching the results when we look up everything (for code completion).
This isn't ideal, but it doesn't seem to be costing too much in performance,
at least not right now, and it means we can get visibility correct.
In the future, it might make sense to include a ClangModuleUnit alongside a
SerializedASTFile for adapter modules, rather than having two separate
modules with the same name. I haven't really thought through this yet, though.
Swift SVN r10834
