Skip to content

Store Clang module imports in addition to Swift overlay. #34037

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 1 commit into from
Sep 24, 2020

Conversation

adrian-prantl
Copy link
Contributor

This helps the debugger resolve types in the underlying Clang module.

rdar://problem/69393097

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

@adrian-prantl
Copy link
Contributor Author

@swift-ci test and merge

void createImportedModule(llvm::DIScope *Context,
ModuleDecl::ImportedModule M, llvm::DIFile *File,
unsigned Line) {
// For cross-import overlay modules also emit an import of the underlying
Copy link
Contributor

Choose a reason for hiding this comment

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

micro-nit: This seems to apply to regular overlays, not cross-import overlays, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe I'm getting confused about the terminology here: I thought that cross-import overlay is synonymous with that it has an underlying Clang module?

Copy link
Contributor

Choose a reason for hiding this comment

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

Nope, that's just a regular overlay. A cross-import overlay is e.g. the _MapKit_SwiftUI module in the SDK, it doesn't necessarily need to involve clang modules at all.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, but the code explicitly checks for an underlying Clang module so I'm not yet sure I understand the concern?

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh the only concern is that the comment is misleading 😅

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's what I don't get (yet) — the comment says cross-module overlays get an extra reference to the underlying clang module and the code only applies to modules with underlying clang modules.

Copy link
Contributor

Choose a reason for hiding this comment

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

Right, but does this only apply to cross-import overlays of clang modules? This seems to apply mostly to regular overlays, I can't see anything that makes this specific to cross-import overlays.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can you explain what the difference between a cross-import overlay of a clang module and a regular overlay of a clang module is? This is what isn't clear to me.

Copy link
Contributor

Choose a reason for hiding this comment

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

A cross-import of a clang module would involve additional metadata bundled with the swiftmodule structure that describes the other modules it can cross-over with. I don't know if we have any examples of one half of the cross being a pure clang module that is not adulterated by a Swift overlay module.

A plain overlay is a Swift module that imports an underlying clang module with the same name and extends declarations contained therein.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok! So "Cross" is an orthogonal concept to the source language of the module. Which is what Harlan said a couple of comment above I now realize... thanks!

@adrian-prantl
Copy link
Contributor Author

@swift-ci test and merge

1 similar comment
@adrian-prantl
Copy link
Contributor Author

@swift-ci test and merge

@shahmishal
Copy link
Member

Please update the base branch to main

  • How to change the base branch: (Link)
  • More detail about the branch update: (Link)

@adrian-prantl adrian-prantl changed the base branch from master to main September 23, 2020 20:14
@adrian-prantl
Copy link
Contributor Author

@swift-ci test and merge

This helps the debugger resolve types in the underlying Clang module.

<rdar://problem/69393097>
@adrian-prantl
Copy link
Contributor Author

@swift-ci smoke test

@adrian-prantl
Copy link
Contributor Author

test with swiftlang/llvm-project#1836
@swift-ci smoke test

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.

4 participants