ping

gentle ping

Fix up patch based on review comments

Handle multiple flags set in llvm-tapi-diff printing

LGTM, thank you!

Apply to older format

Distinct top level libraries vs. nested inlined libraries in format

Rebase

small refactor

Fix printing for unknown deployment verison in older TBDs.

Fix typo

Rebase changes

Add insource documentation on new format & add Tests

Fix Windows build

Fixup invalid test inputs

Fix up format of commit message.

Update lld tests to include .hidden attribute.

This change LGTM. My understanding of the history here, is that these symbols were exported expecting to be eventually referenced when profiling options are used but weren't always consistently exported. This kind of inconsistency of symbol exports breaks TAPI verification. In the recent past we've had a similar issue where the symbols got optimized out based on the optimization level. If __llvm_profile_raw_version and __llvm_profile_filename always have hidden visibility this should be fine for TAPI.

Restrict using the canonical decl's source location to only when the prototype was inferred from previously seen decl.

Hold include name in HeaderSearch itself, keeping HeaderFileInfo lightweight.

In D124638#3481932, @jansvoboda11 wrote:

Can you describe how come the check is not reliable without this patch? It might be worth fixing the underlying reason for the unreliability first.

we might not always want to transform an absolute path because the resulting relative include name might get remapped in a headermap, for example in test known_files_only_hmap.c. But how does it work with modules where we need relative includes? Is the setup in known_files_only_hmap even valid?

LGTM

I followed up about this approach with folks more familiar with SourceKit and seems fine, so LGTM. I'd wait a day to see if Jan has any concerns.

My understanding for the header map restriction is because headermaps are generally emitted once for a framework build and only consumed to build such framework and this struct information is only queried during this.
It sounds like for the clangd support, you're not as interested in what framework is being built, but the name of the framework when included via framework style in any context. Is that correct? It seems fine to extend its use cases. @jansvoboda11 What do you think?

In D111468#3066820, @jansvoboda11 wrote:

LGTM.

As a follow-up, do you think it would make sense to improve the documentation/comments around "index header maps"? Variable names refer to indexing while the documentation talks about building frameworks, which is confusing without referring back to the original Radar.

Fix windows build.