Skip to content

Cherry-pick ([Clang][ScanDeps] Add C API and implement enough to build Foundation.) and follow up fixes into stable 20200108 #754

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 13 commits into from
Feb 8, 2020

Conversation

Bigcheese
Copy link

This cherry-picks #699, it's dependencies, and its subsequent cleanups into apple/stable/20200108.

Differential Revision: https://reviews.llvm.org/D70268

This is a recommit of f978ea4 with a fix for the PowerPC failure.

The issue was that:
* `CompilerInstance::ExecuteAction` calls
  `getTarget().adjust(getLangOpts());`.
* `PPCTargetInfo::adjust` changes `LangOptions::HasAltivec`.
* This happens after the first few calls to `getModuleHash`.

There’s even a FIXME saying:
```
  // FIXME: We shouldn't need to do this, the target should be immutable once
  // created. This complexity should be lifted elsewhere.
```

This only showed up on PowerPC because it's one of the few targets that
almost always changes a hashed langopt.

I looked into addressing the fixme, but that would be a much larger
change, and it's not the only thing that happens in `ExecuteAction` that
can change the module context hash. Instead I changed the code to not
call `getModuleHash` until after it has been modified in `ExecuteAction`.

(cherry picked from commit 356a4b4)
rdar://58857443
(cherry picked from commit 74b01d9)
This adds an experimental C API for clang-scan-deps. It provides both
the full module dependency graph along with a flattened list of
dependencies.

See clang/include/clang-c/Dependencies.h for the API and documentation.

You can test it out using:
c-index-test core --scan-deps <working-directory> -- clang --cc1 <args>

This will output a list of modules and then the direct dependencies of
the main translation unit.

(cherry picked from commit 3e60b06)
This function returns the equivalent of -###

<rdar://problem/49928458>
<rdar://problem/49396121>

(cherry picked from commit 1fdae62)
…e-options

Removes any arguments before this one that would be incompatible with
explicitly building a module. This includes things like -o and input
files. This option can be used to append arguments to convert a build of
a translation unit with implicit modules into an explicit build of a
specific module.

(cherry picked from commit 5286f37)
This assert fires for ObjectiveC id, SEL, and Class declarations when
the module is explicitly built. For implicit builds it works fine.

This reproduces with:

  typedef struct objc_class Class;
  struct objc_class;

As a module imported into another module, and both the above and that
module imported into a third TU.

Changing the name (`Class`) or reordering the declarations does not
assert.

rdar://58552906
(cherry picked from commit 9327c60)
Gives the last of -f{no-}implicit-module-maps precedence.

rdar://58883354
(cherry picked from commit 2d28507)
Building the actual module still fails, but make sure it fails for the
right reason.

(cherry picked from commit 1815e24)
The `UmbrellaAsWritten` and `NameAsWritten` fields in `clang::Module`
are a lie for framework modules. For those they actually are the path to
the header or umbrella relative to the `clang::Module::Directory`.

The exception to this case is for inferred modules. Here it actually is
the name as written, because we print out the module and read it back in
when implicitly building modules. This causes a problem when explicitly
building an inferred module, as we skip the printing out step.

In order to fix this issue this patch adds a new field for the path we
want to use in `getInputBufferForModule`. It also makes `NameAsWritten`
actually be the name written in the module map file (or that would be,
in the case of an inferred module).

rdar://58619519
(cherry picked from commit 0672a6a)
This shows up with inferred modules, but it doesn't exist on disk, so
don't report it as a dependency.

(cherry picked from commit 21c4c10)
(cherry picked from commit 499404c)
@Bigcheese Bigcheese requested review from hyp and dexonsmith February 8, 2020 00:47
@Bigcheese
Copy link
Author

@swift-ci please test

Copy link

@hyp hyp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@Bigcheese Bigcheese merged commit 8bd683f into swiftlang:apple/stable/20200108 Feb 8, 2020
@Bigcheese Bigcheese deleted the scan-deps-stable branch February 8, 2020 02:05
hyp added a commit that referenced this pull request Feb 9, 2020
This reverts commit 8bd683f, reversing
changes made to fe07d64.
@Bigcheese Bigcheese restored the scan-deps-stable branch February 17, 2020 18:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants