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.

In D101835#2798031, @hubert.reinterpretcast wrote:

The tests for this tool are observed to be failing on multiple big-endian platforms:
clang-s390x-linux: https://lab.llvm.org/buildbot/#/builders/94/builds/4116
clang-ppc64be-linux: https://lab.llvm.org/buildbot/#/builders/52/builds/8035

LGTM

LGTM

Thank you!

Address dblaikie's suggestion and move specialization into YAMLTraits.

In D84770#2210049, @sameerarora101 wrote:

In D84770#2208826, @smeenai wrote:

In D84770#2204147, @sameerarora101 wrote:

I think I need to add V8 support under llvm/include/llvm/TextAPI/MachO/Architecture.def here:

///
/// ARM64 architectures sorted by cpu sub type id.
///
ARCHINFO(arm64, MachO::CPU_TYPE_ARM64, MachO::CPU_SUBTYPE_ARM64_ALL, 64)
ARCHINFO(arm64e, MachO::CPU_TYPE_ARM64, MachO::CPU_SUBTYPE_ARM64E, 64)

What should be the first element for that tuple in case of V8 (arm64_v8 or arm64v8 or maybe something else) ? Thanks.

Hmm, what necessitates the TAPI patch? arm64_v8 seems fine to me, though @ributzka and @cishida should weigh in there.

Converting a yaml file with Subtype V8 to an object file requires this patch. I was trying to add a test for V8, but my yaml was incorrectly parsed as an object file with unknown architecture.

In D85594#2207080, @gkm wrote:

@tschuett, I prefer not to do anything that involves semantics for DriverKit, since I don't have any domain knowledge. For that matter, perhaps I shouldn't even follow-through with this diff, which I only embarked upon at your suggestion because the original author of the MachO -platform_version diff (I commandeered it) had a TODO comment. I can code-monkey the TBDv4 testcase via simple substitution, but what about TBDv1 .. TBDv3? IDK, and don't want to spend time determining minimum version# for DriverKit. Do you know that?

Thanks for fixing this! one nit but LGTM

the landed patch has applied MaskRay's comments.

adopintg jhenderson's comments to increase Readablity & Coding Guidelines

Updating to address comments, add more const correctness, fix casing on FileCheck

the lint corrections will be/have been made in the revision that lands.

Updating this patch to just create inlining framework support, and I will attach lib/Object & nm support in a seperate patch