This is an archive of the discontinued LLVM Phabricator instance.

Add clang_CXXMethod_isExplicit to libclang
ClosedPublic

Authored by diseraluca on Dec 29 2022, 2:56 AM.

Details

Summary

The new method is a wrapper of CXXConstructorDecl::isExplicit and
CXXConversionDecl::isExplicit, allowing the user to recognize whether
the declaration pointed to by a cursor was marked with the explicit
specifier.

An export for the function, together with its documentation, was added
to "clang/include/clang-c/Index.h" with an implementation provided in
"clang/tools/libclang/CIndex.cpp".

The implementation is based on similar clang_CXXMethod
implementations, returning a falsy unsigned value when the cursor is not
a declaration, is not a declaration for a constructor or conversion
function or is not a relevant declaration that was marked with the
explicit specifier.

The new symbol was added to "clang/tools/libclang/libclang.map" to be
exported, under the LLVM16 tag.

"clang/tools/c-index-test/c-index-test.c" was modified to print a
specific tag, "(explicit)", for cursors that are recognized by
clang_CXXMethod_isExplicit.

Two new regression files, "explicit-constructor.cpp" and
"explicit-conversion-function.cpp", were added to "clang/test/Index", to
ensure that the behavior of the new function is correct for constructors
and conversion functions, respectively.

The "get-cursor.cpp", "index-file.cpp" and
"recursive-cxx-member-calls.cpp" regression files in "clang/test/Index"
were updated as they were affected by the new "(explicit)" tag.

A binding for the new function was added to libclang's python's
bindings, in "clang/bindings/python/clang/cindex.py", as the
"is_explicit_method" method under Cursor.

An accompanying test was added to
"clang/bindings/python/tests/cindex/test_cursor.py", mimicking the
regression tests for the C side.

The current release note for Clang, "clang/docs/ReleaseNotes.rst" was
modified to report the new addition under the "libclang" section.

Diff Detail

Event Timeline

diseraluca created this revision.Dec 29 2022, 2:56 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 29 2022, 2:56 AM
Herald added a subscriber: arphaman. · View Herald Transcript
diseraluca requested review of this revision.Dec 29 2022, 2:56 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 29 2022, 2:56 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
aaron.ballman accepted this revision.Jan 13 2023, 6:24 AM

LGTM aside from some minor things you can correct when landing.

clang/bindings/python/clang/cindex.py
1550–1557

You might want to add documentation about:

constexpr bool foo(int i) { return i % 2 == 0; }

struct S {
  explicit(foo(1)) S(); // IsExplicit returns false
  explicit(foo(2)) operator int(); // IsExplicit returns true

so it's not about the syntactic element of there being an explicit, it's about what it resolves to.

clang/include/clang-c/Index.h
4364

Same doc suggestions around here as in the Python code.

clang/tools/libclang/CIndex.cpp
8951–8957

Same logic, but spelled differently.

This revision is now accepted and ready to land.Jan 13 2023, 6:24 AM

LGTM aside from some minor things you can correct when landing.
....

Thank you for the great suggestions!

I'll try to correct it as soon as possible, hopefully this weekend.
Should I update the revision or should I just modify it and land it after ensuring that it works correctly?

LGTM aside from some minor things you can correct when landing.
....

Thank you for the great suggestions!

I'll try to correct it as soon as possible, hopefully this weekend.
Should I update the revision or should I just modify it and land it after ensuring that it works correctly?

Thanks for checking! Feel free to modify it and land it after ensuring it works correctly. :-)

This revision was landed with ongoing or failed builds.Jan 23 2023, 2:33 AM
This revision was automatically updated to reflect the committed changes.
diseraluca reopened this revision.Jan 25 2023, 2:24 AM

When I pushed the patch the tests produced failures in buildbot.
I reverted the patch as I did not have the time to check what was happening.

I've now had time to check and the failures seems to be due to the implementation dependent signed-ness of char,
thus failing on platforms where char is unsigned (like power pc).

I've changed the tests to use a more precise unsigned char which should solve the issue.
There is probably a way to only check for the presence or lack thereof of the (explicit) tag without checking those unimportant details,
but I had not time to accustom myself to FileCheck yet.

I reopened the revision to have a second set of eyes check this as I would really like to avoid blocking the integrations again.

This revision is now accepted and ready to land.Jan 25 2023, 2:24 AM

Fixed tests

aaron.ballman accepted this revision.Jan 26 2023, 5:55 AM

The fixes LGTM, thank you!

This revision was landed with ongoing or failed builds.Jan 27 2023, 4:24 AM
This revision was automatically updated to reflect the committed changes.
vedgy added a subscriber: vedgy.Feb 2 2023, 4:20 AM

Hello Luca and Aaron.
I have noticed that you recently implemented/reviewed multiple interesting libclang features, some of which can be used in KDevelop. However, CINDEX_VERSION_MINOR was last modified in Clang 13. This constant's documentation states:

CINDEX_VERSION_MINOR should increase when there are API additions.

Can this constant be incremented in the upcoming Clang 16 release?

Hello Luca and Aaron.
I have noticed that you recently implemented/reviewed multiple interesting libclang features, some of which can be used in KDevelop. However, CINDEX_VERSION_MINOR was last modified in Clang 13. This constant's documentation states:

CINDEX_VERSION_MINOR should increase when there are API additions.

Can this constant be incremented in the upcoming Clang 16 release?

That's a great catch, yes it can. I'll post a patch today to bump it on trunk and then file an issue to cherry-pick it over to the 16.x branch. Thank you!

Hello Luca and Aaron.
I have noticed that you recently implemented/reviewed multiple interesting libclang features, some of which can be used in KDevelop. However, CINDEX_VERSION_MINOR was last modified in Clang 13. This constant's documentation states:

CINDEX_VERSION_MINOR should increase when there are API additions.

Can this constant be incremented in the upcoming Clang 16 release?

That's a great catch, yes it can. I'll post a patch today to bump it on trunk and then file an issue to cherry-pick it over to the 16.x branch. Thank you!

79571aa2103c95760a07e3549d8636379e4948f0 is the commit on main and https://github.com/llvm/llvm-project/issues/60478 is for the 16.x cherry-pick.

vedgy added a comment.Feb 2 2023, 5:57 AM

79571aa2103c95760a07e3549d8636379e4948f0 is the commit on main and https://github.com/llvm/llvm-project/issues/60478 is for the 16.x cherry-pick.

Thank you Aaron! But note that this review's commit ended up in Clang 17, not Clang 16. Previous API additions have been implemented earlier and are included in Clang 16.

79571aa2103c95760a07e3549d8636379e4948f0 is the commit on main and https://github.com/llvm/llvm-project/issues/60478 is for the 16.x cherry-pick.

Thank you Aaron! But note that this review's commit ended up in Clang 17, not Clang 16. Previous API additions have been implemented earlier and are included in Clang 16.

Yup, that's why I opened up the issue to backport it into Clang 16. We don't usually make edits directly to the branch, instead we put them on main and cherry-pick them over to the release branch. Our cherry-picking bot is doing the work (you can see it adding comments to https://github.com/llvm/llvm-project/issues/60478).

vedgy added a comment.Feb 2 2023, 6:18 AM

I meant that the commit message of https://reviews.llvm.org/rG79571aa2103c95760a07e3549d8636379e4948f0 misleadingly refers to this review's commit. But CINDEX_VERSION_MINOR == 63 is for previous commits. This commit will require incrementing CINDEX_VERSION_MINOR again to 64 in Clang 17. Hopefully my preamble-storage patches will also be included in Clang 17 and share the same minor version 64 :)

I meant that the commit message of https://reviews.llvm.org/rG79571aa2103c95760a07e3549d8636379e4948f0 misleadingly refers to this review's commit. But CINDEX_VERSION_MINOR == 63 is for previous commits. This commit will require incrementing CINDEX_VERSION_MINOR again to 64 in Clang 17. Hopefully my preamble-storage patches will also be included in Clang 17 and share the same minor version 64 :)

Hmmm, I thought 0a51bc731bcc2c27e4fe97957a83642d93d989be landed before we did the branch (and so was the last change in Clang 16) and we don't have any new CIndex commits since then to bump it to 64 (yet). However, now I see that it almost made the branch but was reverted https://github.com/llvm/llvm-project/commit/1af716499d6bc29afd9ff2903200890df774859f (though we had other changes in Clang 16 justifying the version bump, such as 5c67cf0a7fdc00c9b9c55578b770e768f5618bed).

So I think you're right, we need one more commit on main to bump to 64 because of 0a51bc731bcc2c27e4fe97957a83642d93d989be. And yes, I think the preamble storage patches will be in Clang 17 and share the same minor version.

vedgy added inline comments.Feb 2 2023, 8:31 AM
clang/tools/libclang/libclang.map
419

This line should be moved from under the LLVM_16 tag to under a new LLVM_17 tag. Alternatively this commit can be cherry-picked into the LLVM 16 branch.

@diseraluca -- do you need this cherry picked into Clang 16 or are you fine if this goes into Clang 17 instead?

vedgy added a comment.Feb 6 2023, 9:16 PM

The added, then reverted release note was lost when this revision landed the second time.

@diseraluca -- do you need this cherry picked into Clang 16 or are you fine if this goes into Clang 17 instead?

I'll go with the assumption this is fine going into Clang 17 and not needing to be cherry-picked. I'll take care of that and the missed release note when I have a spare moment. (Thanks @vedgy for noticing these changes are needed!)

@diseraluca -- do you need this cherry picked into Clang 16 or are you fine if this goes into Clang 17 instead?

I'll go with the assumption this is fine going into Clang 17 and not needing to be cherry-picked. I'll take care of that and the missed release note when I have a spare moment. (Thanks @vedgy for noticing these changes are needed!)

The spare moment came sooner than expected, I've made the changes in de4321cf2cf28f2bae7fc0f1897957e73b726f89.

vedgy added a comment.Feb 9 2023, 10:36 AM

The spare moment came sooner than expected, I've made the changes in de4321cf2cf28f2bae7fc0f1897957e73b726f89.

Isn't the global: label needed in the new LLVM_17 block/tag?

The spare moment came sooner than expected, I've made the changes in de4321cf2cf28f2bae7fc0f1897957e73b726f89.

Isn't the global: label needed in the new LLVM_17 block/tag?

I thought that was the default already, but I see the others do it explicitly, so I will as well.

The spare moment came sooner than expected, I've made the changes in de4321cf2cf28f2bae7fc0f1897957e73b726f89.

Isn't the global: label needed in the new LLVM_17 block/tag?

I thought that was the default already, but I see the others do it explicitly, so I will as well.

Added in 4c84c1314716392061215aac7f299493bdf3cc93

@diseraluca -- do you need this cherry picked into Clang 16 or are you fine if this goes into Clang 17 instead?

Sorry for checking in so late, I noticed the notifications only now. We are using a different solution for the time being so it is correct that this is fine being in Clang 17.

Thank you for taking care of this.

@diseraluca -- do you need this cherry picked into Clang 16 or are you fine if this goes into Clang 17 instead?

Sorry for checking in so late, I noticed the notifications only now. We are using a different solution for the time being so it is correct that this is fine being in Clang 17.

Thank you for taking care of this.

Thank you for the info!