This is primarily meant to used for testing LLDB's DWARFImporterDelegate,
however, this could become the default option for LLDB once
DWARFImporterDelegate is sufficiently mature.
<rdar://problem/57880844>
- No need to hash input values first
- Pass many values to a single hash_combine to save on intermediates
- Use hash_combine_range instead of a loop of hash_combines
No functionality change.
While most -Xcc options turn into options that affect the Clang module
cache hash, some, like search paths, do not, and that can have a
drastic effect on PCH contents. When combined with places where Xcode
will modify invocations to add extra -Xcc options (see
rdar://problem/23297285), this can lead to crashes where the
modified-invocation PCH is used to compile source files in incremental
mode, and then the original, non-precompiled bridging header is used
for module merging. Let's just be conservative and include -Xcc
options in the Swift-side PCH uniqueness hash.
rdar://problem/33837253
The clang importer has to deal with two virtual file systems, one coming
from clang, and one coming from swift. Currently, if both are set, we
emit a diagnostic that we'll pick the swift one.
This commit changes that, by merging the two virtual file systems. The
motivation for this change is the reproducer infrastructure in LLDB,
which adds a third virtual file system to the mix.
(cherry picked from commit 94ef5431ff)
The point of this flag is to avoid re-checking the whole SDK on every
build, since under many circumstances you can assume it hasn't
changed. That worked for Clang modules, but Swift cached modules also
end up with dependencies that shouldn't be updated.
rdar://problem/53279521
Way back in Swift 1 I was trying to draw a distinction between
"overlays", separate libraries that added Swift content to an existing
Objective-C framework, and "the Swift part of a mixed-source
framework", even though they're implemented in almost exactly the same
way. "Adapter module" was the term that covered both of those. In
practice, however, no one knew what "adapter" meant. Bring an end to
this confusion by just using "overlay" within the compiler even for
the mixed-source framework case.
No intended functionality change.
This works a around search path problems caused by a module existing
in both the build/install directory and the source directory.
<rdar://problem/35714074>
For the multiple-files mode -emit-pch is still invoked in separate frontend invocation but with using a persistent PCH.
Subsequent frontend invocations use the persistent PCH but they don't need to validate it.
For all-files mode (e.g. WMO) the frontend invocation uses a persistent PCH that it also validates.
- Add CompilerInvocation::getPCHHash
This will be used when creating a unique filename for a persistent
precompiled bridging header.
- Automatically generate and use a precompiled briding header
When we're given both -import-objc-header and -pch-output-dir
arguments, we will try to:
- Validate what we think the PCH filename should be for the bridging
header, based on the Swift PCH hash and the clang module hash.
- If we're successful, we'll just use it.
- If it's out of date or something else is wrong, we'll try to
emit it.
- This gives us a single filename which we can `stat` to check for the
validity of our code completion cache, which is keyed off of module
name, module filename, and module file age.
- Cache code completion results from imported modules
If we just have a single .PCH file imported, we can use that file as
part of the key used to cache declarations in a module. Because
multiple files can contribute to the __ObjC module, we've always given
it the phony filename "<imports>", which never exists, so `stat`-ing it
always fails and we never cache declarations in it.
This is extremely problematic for projects with huge bridging headers.
In the case where we have a single PCH import, this can bring warm code
completion times down to about 500ms from over 2-3s, so it can provide a
nice performance win for IDEs.
- Add a new test that performs two code-completion requests with a bridging header.
- Add some -pch-output-dir flags to existing SourceKit tests that import a bridging
header.
rdar://problem/31198982
Fixes rdar://problem/14776565 (AnyObject lookup for Objective-C
properties with custom getters) and rdar://problem/17184411 (allowing
__attribute__((swift_name("foo"))) to work on anything).
We decided not to support "implicit" properties, where we import
getter/setter pairs as properties. Rather, we only import a property
when there is an explicit "@property" in Objective-C. Remove the flag
and supporting code for implicit properties.
Most of this is in updating the standard library, SDK overlays, and
piles of test cases to use the new names. No surprises here, although
this shows us some potential heuristic tweaks.
There is one substantive compiler change that needs to be factored out
involving synthesizing calls to copyWithZone()/copy(zone:). Aside from
that, there are four failing tests:
Swift :: ClangModules/objc_parse.swift
Swift :: Interpreter/SDK/Foundation_test.swift
Swift :: Interpreter/SDK/archiving_generic_swift_class.swift
Swift :: Interpreter/SDK/objc_currying.swift
due to two independent remaining compiler bugs:
* We're not getting partial ordering between NSCoder's
encode(AnyObject, forKey: String) and NSKeyedArchiver's version of
that method, and
* Dynamic lookup (into AnyObject) doesn't know how to find the new
names. We need the Swift name lookup tables enabled to address this.
When we parse a bridging header, start building a mapping from Swift
names (both base names and full names) to the Clang declarations that
have those names in particular Clang contexts. For now, just provide
the ability to build the table (barely) and dump it out; we'll grow
it's contents in time.
My temporary hackery around inferring default arguments from imported
APIs was too horrible. Make it slightly more sane by:
1) Actually marking these as default arguments in the type system,
rather than doing everything outside of the type system. This is a
step closer to what we would really do, if we go in this
direction. Put it behind the new -frontend flag
-enable-infer-default-arguments.
2) Only inferring a default argument from option sets and from
explicitly "nullable" parameters, as stated in the (Objective-)C API
or API notes. This eliminates a pile of spurious, non-sensical "=
nil"'s in the resulting output.
Note that there is one ugly tweak to the overloading rules to prefer
declarations with fewer defaulted arguments. This is a bad
implementation of what is probably a reasonable rule (prefer to bind
fewer default arguments), which intentionally only kicks in when we're
dealing with imported APIs that have default arguments.
Swift SVN r32078
The -enable-omit-needless-words option attempts to omit needless words
from method names imported from Clang. Broadly speaking, a word is
needless if it merely restates the type of the corresponding parameter,
using reverse camel-case matching of the type name to the
function/parameter name. The word "With" is also considered needless
if whether follows it is needless, e.g.,
func copyWithZone(zone: NSZone)
gets reduced to
func copy(zone: NSZone)
because "Zone" merely restates type information and the remaining,
trailing "With" is also needless.
There are some special type naming rules for builtin Objective-C types,
e.g.,
id -> "Object"
SEL -> "Selector"
Block pointer types -> "Block"
as well as some very-Cocoa-specific matching rules, e.g., the type
"IndexSet" matches the name "Indexes" or "Indices".
Expect a lot of churn with these heuristics; this is part of
rdar://problem/22232287.
Swift SVN r31178
This should have no functionality change, but is supposed to keep us from
accidentally relying on the "full" Clang importer when in a backend job.
I tested it by archiving a little iOS app from a developer.
Unfortunately, part of the motivation here was that we'd get error messages when
we pass something Clang doesn't like, and that doesn't seem to be happening.
rdar://problem/21389553
Swift SVN r30407
Previously we hardcoded a few important default CPUs, ABIs, and features into
Swift's driver, duplicating work in Clang. Now that we're using Clang's
driver to create the Clang "sub-compiler", we can delegate this work to Clang.
As part of this, I've dropped the options for -target-abi (which was a
frontend-only option anyway) and -target-feature (which was a hidden driver
option and is a frontend-only option in /Clang/). We can revisit this later
if it becomes interesting. I left in -target-cpu, which is now mapped
directly to Clang's -mcpu=.
Swift SVN r22449
This can be used by SourceKit's interface printer to display modules with
forward declarations of classes in dependent modules, e.g. ObjectiveC
forward-declaring Foundation's NSString for use in NSObject. We can consider
doing something similar for C tag types (structs and enums).
Part of rdar://problem/18273845
Swift SVN r21828
