David Farler 65668c9d82 Cache Code Completion results from PCH files ...

- 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

2017-04-04 20:44:33 -07:00

12 KiB

Raw Blame History

View Raw