Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[Clang][ScanDeps] Add C API and implement enough to build Foundation. #699

Merged
merged 10 commits into from Feb 4, 2020
Merged

[Clang][ScanDeps] Add C API and implement enough to build Foundation. #699

merged 10 commits into from Feb 4, 2020

Conversation

Bigcheese
Copy link

This adds an experimental C API to clang-scan-deps and implements enough to build the Foundation module and everything it depends on. See individual commit messages for details.

@Bigcheese
Copy link
Author

@swift-ci please test

dexonsmith
dexonsmith approved these changes Jan 31, 2020
View reviewed changes
Copy link

@dexonsmith dexonsmith left a comment

Choose a reason for hiding this comment

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

I'm fine with this being on apple/master temporarily, as long as we continue to push forward on getting this reviewed at llvm.org in parallel.

@Bigcheese
Copy link
Author

Test failure was due to non determinism in the output. Fixed by sorting file-deps in the C API.

@swift-ci please test

@Bigcheese
[clang][clang-scan-deps] Add an experimental C API.
3e60b06 
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.
@Bigcheese
[libclang] Add clang_Driver_getExternalActionsForCommand_v0
1fdae62 
This function returns the equivalent of -###

<rdar://problem/49928458>
<rdar://problem/49396121>
@Bigcheese
[Clang][cc1] Add -remove-preceeding-explicit-module-build-incompatibl…
5286f37 
…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.
@Bigcheese
[Clang][ScanDeps] Actually pass the non path command line modifications.
b05c4d3
@Bigcheese
[Clang][ScanDeps] Use the module map a module was inferred from for i…
3eae6a8 
…nferred modules.
@Bigcheese
[Clang] Temporarily comment out assert.
9327c60 
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
@Bigcheese
[Clang][cc1] Support -fno-implicit-module-maps in -cc1.
2d28507 
Gives the last of -f{no-}implicit-module-maps precedence.

rdar://58883354
@Bigcheese
[Clang] Allow explicitly building an inferred module.
1815e24 
Building the actual module still fails, but make sure it fails for the
right reason.
@Bigcheese
[Clang] Fix the header paths in clang::Module for inferred modules.
0672a6a 
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
@Bigcheese
[Clang][ScanDeps] Ignore __inferred_module.map dependency.
21c4c10 
This shows up with inferred modules, but it doesn't exist on disk, so
don't report it as a dependency.
@Bigcheese
Copy link
Author

I was not able to reproduce the previous test failure. Trying again.

@swift-ci please test

@Bigcheese
Copy link
Author

I was able to confirm that the failing tests were already failing on master, and aren't related to this change.

@Bigcheese Bigcheese merged commit 7a8a697 into apple:apple/master Feb 4, 2020
@Bigcheese Bigcheese mentioned this pull request Feb 8, 2020
Merged
jansvoboda11 pushed a commit to llvm/llvm-project that referenced this pull request May 17, 2021
@Bigcheese @jansvoboda11
[clang][modules] Build inferred modules
d3676d4 
This patch enables explicitly building inferred modules.

Effectively a cherry-pick of apple#699 authored by @Bigcheese with libclang and dependency scanner changes omitted.

Contains the following changes:

1. [Clang] Fix the header paths in clang::Module for inferred modules.
  * 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).

2. [Clang] Allow explicitly building an inferred module.
  * Building the actual module still fails, but make sure it fails for the right reason.

Split from D100934.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D102491
jansvoboda11 pushed a commit to llvm/llvm-project that referenced this pull request May 17, 2021
@Bigcheese @jansvoboda11
[clang][deps] Support inferred modules
1d9e8e1 
This patch adds support for inferred modules to the dependency scanner.

Effectively a cherry-pick of apple#699 authored by @Bigcheese with libclang and other changes omitted.

Contains following changes:

1. [Clang][ScanDeps] Ignore __inferred_module.map dependency.
  * This shows up with inferred modules, but it doesn't exist on disk, so don't report it as a dependency.

2. [Clang][ScanDeps] Use the module map a module was inferred from for inferred modules.

Also includes a smoke test that uses clang-scan-deps output to perform an explicit build. There's no intention to duplicate whatever `test/Modules` contains, just to verify the produced command-line does "work" (with very loose definition of work).

Split from D100934.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D102495
arichardson pushed a commit to arichardson/llvm-project that referenced this pull request Sep 12, 2021
@Bigcheese @arichardson
[clang][modules] Build inferred modules
c35f6be 
This patch enables explicitly building inferred modules.

Effectively a cherry-pick of apple/llvm-project#699 authored by @Bigcheese with libclang and dependency scanner changes omitted.

Contains the following changes:

1. [Clang] Fix the header paths in clang::Module for inferred modules.
  * 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).

2. [Clang] Allow explicitly building an inferred module.
  * Building the actual module still fails, but make sure it fails for the right reason.

Split from D100934.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D102491
arichardson pushed a commit to arichardson/llvm-project that referenced this pull request Sep 12, 2021
@Bigcheese @arichardson
[clang][deps] Support inferred modules
9a65bbe 
This patch adds support for inferred modules to the dependency scanner.

Effectively a cherry-pick of apple/llvm-project#699 authored by @Bigcheese with libclang and other changes omitted.

Contains following changes:

1. [Clang][ScanDeps] Ignore __inferred_module.map dependency.
  * This shows up with inferred modules, but it doesn't exist on disk, so don't report it as a dependency.

2. [Clang][ScanDeps] Use the module map a module was inferred from for inferred modules.

Also includes a smoke test that uses clang-scan-deps output to perform an explicit build. There's no intention to duplicate whatever `test/Modules` contains, just to verify the produced command-line does "work" (with very loose definition of work).

Split from D100934.

Reviewed By: dexonsmith

Differential Revision: https://reviews.llvm.org/D102495
vgvassilev pushed a commit to vgvassilev/clang that referenced this pull request Dec 28, 2022
@Bigcheese @vgvassilev
[clang][modules] Build inferred modules
568fbce 
This patch enables explicitly building inferred modules.

Effectively a cherry-pick of apple/llvm-project#699 authored by @Bigcheese with libclang and dependency scanner changes omitted.

Contains the following changes:

1. [Clang] Fix the header paths in clang::Module for inferred modules.
  * 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).

2. [Clang] Allow explicitly building an inferred module.
  * Building the actual module still fails, but make sure it fails for the right reason.

Split from D100934.

Reviewed By: dexonsmith

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

llvm-monorepo: d3676d4b666ead794fc58bbc7e07aa406dcf487a
vgvassilev pushed a commit to vgvassilev/clang that referenced this pull request Dec 28, 2022
@Bigcheese @vgvassilev
[clang][deps] Support inferred modules
4c5c82b 
This patch adds support for inferred modules to the dependency scanner.

Effectively a cherry-pick of apple/llvm-project#699 authored by @Bigcheese with libclang and other changes omitted.

Contains following changes:

1. [Clang][ScanDeps] Ignore __inferred_module.map dependency.
  * This shows up with inferred modules, but it doesn't exist on disk, so don't report it as a dependency.

2. [Clang][ScanDeps] Use the module map a module was inferred from for inferred modules.

Also includes a smoke test that uses clang-scan-deps output to perform an explicit build. There's no intention to duplicate whatever `test/Modules` contains, just to verify the produced command-line does "work" (with very loose definition of work).

Split from D100934.

Reviewed By: dexonsmith

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

llvm-monorepo: 1d9e8e13dd7b3204fa51ada17d1608bdbd1bed66
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@dexonsmith dexonsmith dexonsmith approved these changes

@hyp hyp Awaiting requested review from hyp

@bcardosolopes bcardosolopes Awaiting requested review from bcardosolopes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@Bigcheese @dexonsmith