LGTM with minor changes

Great start but there are still some rough edges to polish!

LGTM

LGTM

Do we still have a test that ensures that actually writing the property attributes manually results in them being added to the declaration fragments?

You will need to rebase this as I made some changes recently to how ExtractAPIVisitor is structured. We can either set up a time to talk about it and do it together or I can handle doing this work once we are happy with this.

In D146656#4220022, @zixuw wrote:

LGTM for the ExtractAPIVisitor part.
Remaining:

• update test with @LINE
• the libclang side

Yup looks fine to me!

LGTM, but you should also check in the test that id still renders as expected.

Adding back missing diffs.

Addressing code review feedback

LGTM! I think it's fine to go ahead and land this (premerge check are not a requirement). Have you contributed to LLVM before? If not I will need to commit it on your behalf. Once that is done you should follow the instructions at https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access to gain commit access if you wish to continue contributing to the project and LLVM in general.

I think there might be some code missing here. Also can you add a test?

LGTM once you fix the test

LGTM, It's worth noting that if the user specifies that an API is unavailable in a later redeclaration, this will be ignored. For example if I add a line to the test void e(void) __attribute__((availability(macos, unavailable))); it will be ignored. Up to you whether you want to fix it now or at a later date.

In D144940#4158143, @Arsenic wrote:

In D144940#4158020, @dang wrote:

Nice! glad to see this getting fixed. You should add a lit test to ensure we don't regress this behavior in the future.

I see a test checking for availability attribute already exists ( clang/test/ExtractAPI/availability.c ) would it be better if I update it with another function having a platform specific unavailability attribute or should I create a new test file ?

Nice! glad to see this getting fixed. You should add a lit test to ensure we don't regress this behavior in the future.

LGTM for the ExtractAPI changes.

Formatting fixes

Rename new libclang APIs to make the names more readable.

Rebase and fix clang format issue

Address code review feedback regarding libclang specific work.

Add comment explaining that the associated declaration in Declaration Fragments
is not intended to be used outside of libclang

Fix whitespace again

Fix whitespace issues

Fix code review feedback and ensure that all data is initialized before first
use.

Removing some accidental unneeded includes that were tripping up CI.

However, I am not sure it's worthwhile and we might run into edge cases doing it this way with explicitly ignored symbols.

In D136455#3879849, @zixuw wrote:

Is it easy to/worth checking if the target is actually outside of the current module to keep the output smaller and concise?

In D134813#3838069, @zixuw wrote:

With the PrintingPolicy fix in https://reviews.llvm.org/D135295 and landed USR fix, the diff within ExtractAPI tests is only the wording with anonymous enums, and we can drop the lit change:

658c658
<             "spelling": "(anonymous)"
---
>             "spelling": "enum (unnamed)"
661c661
<         "title": "(anonymous)"
---
>         "title": "enum (unnamed)"
664c664
<         "(anonymous)"
---
>         "enum (unnamed)"
706c706
<         "(anonymous)",
---
>         "enum (unnamed)",
746c746
<             "spelling": "(anonymous)"
---
>             "spelling": "enum (unnamed)"
749c749
<         "title": "(anonymous)"
---
>         "title": "enum (unnamed)"
752c752
<         "(anonymous)"
---
>         "enum (unnamed)"
794c794
<         "(anonymous)",
---
>         "enum (unnamed)",

@dang @QuietMisdreavus for this change.

Remove doc comments in test