This is an archive of the discontinued LLVM Phabricator instance.

Expose QualType::getUnqualifiedType in libclang
ClosedPublic

Authored by diseraluca on Aug 26 2022, 10:05 AM.

Details

Summary

The method is now wrapped by clang_getUnqualifiedType.

A declaration for clang_getUnqualifiedType was added to
clang-c/Index.h to expose it to user of the library.

An implementation for clang_getUnqualifiedType was introduced in
CXType.cpp that wraps the equivalent method of the underlying
QualType of a CXType.

An export symbol was added to libclang.map under the new version entry
LLVM_16.

A test was added to LibclangTest.cpp that tests the removal of
qualifiers for some CXTypes.

Diff Detail

Event Timeline

diseraluca created this revision.Aug 26 2022, 10:05 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 26 2022, 10:05 AM
Herald added a subscriber: arphaman. · View Herald Transcript
diseraluca requested review of this revision.Aug 26 2022, 10:05 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 26 2022, 10:05 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript

I recently encountered a few cases, at work, as an employee of The Qt Company, where we would have liked to have access to getUnqualifiedType in libclang.

I found a precedence on the old mailing list, from 2018 (https://lists.llvm.org/pipermail/cfe-dev/2018-February/056874.html), for a similar request, where it seemed it wouldn't be disruptive to expose it to libclang.

This is my first contribution to llvm-project, so I apologize if I missed some requirement or pushed a patch that is incorrect.
I'm obviously open to spend more time on this patch if there is something that should be modified.

Originally the patch contained the addition of clang_getNonReferenceType too, as that is something else that we would like to have access to.
I avoided including it into this patch because:

  • As I understand it, having both in one patch would not comply with the isolated changes requirement in https://www.llvm.org/docs/Contributing.html#how-to-submit-a-patch.
  • I could not find any precedence for requesting that specific interface and am unsure if the correct etiquette requires that a discussion is opened BEFORE pushing this kind of patch.
  • First pushing a smaller patch would allow me to get accustomed to the contributing workflow and understand what I might have done incorrectly, so as to push an higher quality patch.

Any clarification on if a patch that exposes getNonReferencedType requires a discussion to be opened before being pushed for acceptance and review is appreciated.

aaron.ballman accepted this revision.Aug 26 2022, 11:53 AM

I found a precedence on the old mailing list, from 2018 (https://lists.llvm.org/pipermail/cfe-dev/2018-February/056874.html), for a similar request, where it seemed it wouldn't be disruptive to expose it to libclang.

Yup! FWIW, we will add things to libclang as people say they found a need for them (we do similar for AST matchers). We mostly just want to avoid trying to expose all of the APIs through a C interface, as that causes significant maintenance burden given how rapidly our APIs change.

This is my first contribution to llvm-project, so I apologize if I missed some requirement or pushed a patch that is incorrect.
I'm obviously open to spend more time on this patch if there is something that should be modified.

Welcome to the community!

Originally the patch contained the addition of clang_getNonReferenceType too, as that is something else that we would like to have access to.

That seems perfectly reasonable to me as well.

I avoided including it into this patch because:

  • As I understand it, having both in one patch would not comply with the isolated changes requirement in https://www.llvm.org/docs/Contributing.html#how-to-submit-a-patch.
  • I could not find any precedence for requesting that specific interface and am unsure if the correct etiquette requires that a discussion is opened BEFORE pushing this kind of patch.
  • First pushing a smaller patch would allow me to get accustomed to the contributing workflow and understand what I might have done incorrectly, so as to push an higher quality patch.

Any clarification on if a patch that exposes getNonReferencedType requires a discussion to be opened before being pushed for acceptance and review is appreciated.

Feel free to put up a new review for that and add me as a reviewer, I'm happy to look at it. It should be a separate patch because we like to keep patches logically separate in case we need to revert something (no sense in losing all the good changes along with the bad by sticking them all in one patch). It's also far easier to review a patch without a lot of moving parts to it.

In terms of this patch, it looks good to me, but can you add a release note for the improvement? (We have a section for libclang that this should go under.) Once you post the patch with the release note, I'm happy to land this on your behalf (assuming precommit CI doesn't find any surprises I missed). What name and email address would you like used for patch attribution?

This revision is now accepted and ready to land.Aug 26 2022, 11:53 AM

Added a note to the release-notes.

diseraluca added a comment.EditedAug 27 2022, 3:02 AM

Welcome to the community!

Thank you for the kind welcome!

Feel free to put up a new review for that and add me as a reviewer, I'm happy to look at it

Thank you, I'll be sure to do that.

In terms of this patch, it looks good to me, but can you add a release note for the improvement?

This should be done now.

What name and email address would you like used for patch attribution?

Name: Luca Di Sera
email: disera [dot] luca [at] gmail [dot] com

Is there a way for me to configure this so that it is picked up automatically?

tbaeder added inline comments.
clang/include/clang-c/Index.h
3775

Typo: Unuqualified

3779

Same

3792

Typo: Volative

Fixed some typos in the added documentation of clang_getUnqualifiedType.

diseraluca marked 3 inline comments as done.Aug 27 2022, 6:47 AM
This revision was landed with ongoing or failed builds.Aug 29 2022, 5:17 AM
This revision was automatically updated to reflect the committed changes.