Swift will use the basename + argument names formulation for
names. Update the DeclName interfaces, printing, and __FUNCTION__ to
use the method syntax.
We'll still need to rework the "x.foo:bar:wibble:" syntax; that will
come (significantly) later.
Swift SVN r15763
The frontend/driver flag is "-application-extension'. This
activates a language option which will be used for more restrictive
availability checking.
Operationally, this also passes...
- "-fapplication-extension" to the clang importer
- "-application_extension" to ld
Swift SVN r15543
When we see an unresolved @class in a Clang module, we check the class name
against the classes in the Swift module with the same name.
This unfortunately necessitates putting a reference to the active type checker
into the ClangImporter, because the class in the current Swift module hasn't
been type-checked yet. This is now being used everywhere we do a lookup.
<rdar://problem/16295994>
Swift SVN r15355
of 'init' method family with Clang (it looks like 'init123' would count as init
method in Clang, but not in the initial implementation of selector splitting in
Swift).
Swift SVN r15189
The frontend option -split-objc-selectors splits the first part of an
Objective-C selector into both a function name and the first parameter
name at the last preposition. For example, this Objective-C method:
- (NSString *)stringByPaddingToLength:(NSUInteger)newLength withString:(NSString *)padString startingAtIndex:(NSUInteger)padIndex
is imported as
func stringByPadding toLength(newLength: Int) withString(padString: String) startingAtIndex(padIndex: Int) -> String
Swift SVN r15156
In a framework containing both Clang headers and a Swift module, the Swift
module gets picked up first, but then automatically imports (and re-exports)
the Clang module as well.
One interesting case here is that it's possible for the Clang side to add
categories to a class declared in Swift. In order to support this, the
Clang importer can now find extensions for Swift classes marked @objc.
(I couldn't think of a way to test this separately; the previous commit
was supposed to do that, but worked without this change.)
<rdar://problem/16295937>
Swift SVN r15084
This is the same as the previous commit, but for protocols. To do this I
had to modify the ObjC printer to include a SWIFT_PROTOCOL annotation like
the SWIFT_CLASS annotation already in use. This is probably a good thing
anyway.
Second half of <rdar://problem/16296027>
Swift SVN r14985
This is necessary to handle Swift code using API defined in Objective-C
that itself uses classes defined in Swift. Protocols coming next.
First half of <rdar://problem/16296027>
Swift SVN r14984
...so that the Clang module machinery will check that the generated pcm
is up-to-date.
We probably want this to be considered a system header in the long run,
but this is a quick fix for those working on the standard library.
<rdar://problem/16285900>
Swift SVN r14926
In Sema, give derived '==' definitions the module's DerivedFileUnit as their decl context instead of the more general Module, and give it a backreference to the nominal type for which it was derived.
In SILGen, visit the derived global decls associated with Clang-imported enums, and give them shared linkage. Part of fixing <rdar://problem/16264703>.
Swift SVN r14875
In these cases, disable the standard system include paths so we don't
accidentally pick up headers in /.
This is going to be used by the runtime team for low-level interfaces with
C and Objective-C in the standard library.
Swift SVN r14789
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
This will allow us to ship headers that are used by the standard library.
They will be treated as system headers.
<rdar://problem/16227202>
Swift SVN r14757
The former is an obvious fix; the latter is a speed optimization when using
the Debug REPL. Running the crashing code through -i will get nearly the
same effect with verification turned on.
Swift SVN r14468
This is hidden behind the frontend flag -enable-objc-optional. Use -Xfrontend
when invoking the Swift driver.
Part of <rdar://problem/15189135>
Swift SVN r14332
This is more in line with all other modules currently on our system.
If/when we get our final name for the language, we're at least now set
up to rename the library without /too/ much trouble. (This is mostly just
a lot of searching for "import swift", "swift.", "'swift'", and '"swift"'.
The compiler itself is pretty much just using STDLIB_NAME consistently now,
per r13758.)
<rdar://problem/15972383>
Swift SVN r14001
This is needed for the implicit conformances we synthesize. Remove a
hack from TypeCheckConstraints to find swift.~= now that it's available
using normal lookup.
<rdar://problem/15410928>
Swift SVN r13850
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 keeps us from having to deal with fat swiftmodules for now.
In the long run we're hoping to solve this problem with build configurations,
so that a single module file can support multiple architectures.
(See <rdar://problem/15056323>)
<rdar://problem/15204953>
Swift SVN r13135
Hardcoding a path to a particular SDK is definitely the wrong thing to do.
Let's see how far we can get without setting a default SDK.
See discussion in <rdar://problem/14395800>
Swift SVN r12414
This can happen when importing a decl causes a new Swift module to be loaded
(because it uses one of our bridged types), which then brings in a new Clang
module. In this case we have no choice but to throw out the existing cache
and start over. We do keep a map of everything we've imported already, though,
so at least we don't have to do that part again.
This appears to make r12309 unnecessary for correctness, but it probably still
makes performance more consistent.
<rdar://problem/15785883>
Swift SVN r12336
Clang's LookupVisibleDecls is implemented by iterating over the map of lookups,
which clearly isn't deterministic. This *shouldn't* be a problem, but it
seems our importer has non-determinism based on the order it sees decls.
For now, at least, let's make this deterministic up front so that we don't get
weird results from :print_module.
See <rdar://problem/15785883> and <rdar://problem/15799697>.
Swift SVN r12309
