There's now a difference between "this file provides a particular type" and
"this file provides members on a particular type". Adding a conformance in
an extension is still considered "providing a type" because it can affect
things besides just lookups.
This modifies the swiftdeps file output (including the members used by a file),
but the driver hasn't been updated to take advantage of this yet.
Swift SVN r30285
Right now we just have one notion of providing or using a type (as opposed to a
name). It doesn't matter if you're doing lookups, or checking conformance, or
inheriting from a superclass or protocol -- they're all in the same bucket. I'd
like to split these out so that extending a commonly-used type (like, say, Array)
doesn't cause every file in your target to depend on your extension.
This commit doesn't do anything but start tracking which member names are looked
up. For the other things you can do with a type, it's using a dummy empty name.
Swift SVN r30284
- (depends|provides)-top-level for top-level names.
- (depends|provides)-nominal for access into nominal types.
- (depends|provides)-dynamic-lookup for @objc members available on AnyObject.
- depends-external for cross-module file-based dependencies.
No functionality change.
Swift SVN r30283
My 'declIsPrivate' predicate was too conservative: it saw a PatternBindingDecl,
didn't know what it was, and decided that meant it might not be private. Now it's
actually checking the decl kind and doing something reasonable for non-ValueDecls.
Swift SVN r30282
That's how everything behaved anyway. Might as well make it explicit and
stop special-casing it.
I've left in compatibility for modules built with older compilers so that
people using the OS toolchains aren't immediately unable to debug their apps.
As soon as we change the module format in a more significant way, I can take
this out.
Groundwork for rdar://problem/21254367; see next commit.
Swift SVN r29437
Adding a bang can be unsafe and may lead to silently adding crashes in user's code.
Err on the side of caution and let the compiler error stand so the user can review the code.
Swift SVN r28467
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
Mixed-source targets generally include the generated <Product>-Swift.h
header in many Objective-C (.m) source files. Any change to a Swift file
results in the header being touched, which means all the .m files get
recompiled.
This change makes Swift write the generated header to a temporary file
first, then use the previous commit's moveFileIfDifferent to put it in
its final destination.
rdar://problem/20553459
Swift SVN r28042
... with disabled test 1_stdlib/Bit.swift for ios.
Most likely the problem of 1_stdlib/Bit.swift (only on armv7) is just uncovered by this change.
Unfortunately I have no possibility to debug the problem on a device. Therefore I filed rdar://problem/20521110
Swift SVN r27274
This avoids that an unoptimized imported function is linked instead the optimized version from the stdlib.
rdar://problem/20485253
It gives considerable performance improvmenets for some benchmarks with -Onone. E.g.
PopFrontUnsafePointer: +281%
ArrayOfPOD: +92%
StrComplexWalk: +91%
ArrayOfGenericPOD: +61%
Several others are within the range of +10% to +30%.
For the implementation I added runSILPassesForOnone() in Passes.cpp.
Here we can add other optimizations for -Onone in the future.
Swift SVN r27206
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
This will be needed for split-llvm code generation.
If multiple -o options are specified and only a single output file is needed
(currently always), the last one wins. This is NFC.
Swift SVN r25884
Move helper function EmbedBitcode() from frontend_main.cpp to IRGen.cpp so we
can call it from performIRGeneration when the input file is Swift.
Add testing case to make sure that -embed-bitcode-marker option adds an
empty LLVM bitcode section.
rdar://19048891
Swift SVN r25577
With -embed-bitcode, save a copy of the llvm IR as data in the __LLVM,__bitcode
section and save the command-line options in the __LLVM,__cmdline section.
rdar://19048891
Swift SVN r25560
Separate InputFileKind from SourceFileKind, FrontendOptions will now use
InputFileKind, while Module will use SourceFileKind.
This is in preparation for adding an input file kind for LLVM IR.
rdar://19048891
Swift SVN r25555
For now, just emit a warning. Later on we can actually get this right for
multiple files.
This is important for people manually trying to reduce run lines that come
from Xcode.
rdar://problem/19786899
Swift SVN r25388
...so that the debugger has the best possible chance of being able to load
the app properly.
We don't do this for frameworks today because we don't want to leak this
information into the public module; once we have a distinction between
"the module that ships with the framework" and "the module that goes into
the debug info" we can do this for frameworks as well.
Part of rdar://problem/17670778
Swift SVN r25204
Yes, they may not be correct, but the stale ones that were there before
won't be correct either (if they were there at all). This should make both
Xcode and the Swift driver less likely to have issues when there's an error
in a newly added file.
Goes with rdar://problem/19640006
Swift SVN r24824
There's also a testing option, -serialize-debugging-options, to force this
extra info to be serialized even for library targets. In the long run we'll
probably write out this information for all targets, but strip it out of
the "public module" when a framework is built. (That way it ends up in the
debug info's copy of the module.)
Incidentally, this commit includes the ability to add search paths to the
Clang importer on the fly, which is most of rdar://problem/16347147.
Unfortunately there's no centralized way to add search paths to both Clang
/and/ Swift at the moment.
Part of rdar://problem/17670778
Swift SVN r24545
PrintAsObjC behaves slightly differently in apps vs. frameworks: for apps,
you get internal decls exposed in the header as well as public ones. This
is because the generated header is not being shipped anywhere and thus we
don't have a secrecy leak.
However, we were detecting whether we were in an app based on whether or
not we had a bridging header. That's no good for mixed-source apps where
there's no bridging header, so now we also check for a main entry point,
whether generated from @UIApplicationMain or @NSApplicationMain, or from
a script source file (main.swift).
rdar://problem/17877235
Swift SVN r24532
This has been long in coming. We always had it in IRGenOpts (in string form).
We had the version number in LangOpts for availability purposes. We had to
pass IRGenOpts to the ClangImporter to actually create the right target.
Some of our semantic checks tested the current OS by looking at the "os"
target configuration! And we're about to need to serialize the target for
debugging purposes.
Swift SVN r24468
Changing the design of this to maintain more local context
information and changing the lookup API.
This reverts commit 4f2ff1819064dc61c20e31c7c308ae6b3e6615d0.
Swift SVN r24432
