This is an archive of the discontinued LLVM Phabricator instance.

[clang] extend external_source_symbol attribute with the USR clause
ClosedPublic

Authored by arphaman on Jan 9 2023, 1:38 PM.

Details

Summary

Allow the user to specify a concrete USR in the external_source_symbol attribute. That will let Clang's indexer to use Swift USRs for Swift declarations that are represented with C++ declarations.

To allow the sources to conditionally enable this new extension, __has_feature is extended in Clang:

__has_feature(attribute_external_source_symbol_with_usr)

Diff Detail

Event Timeline

arphaman created this revision.Jan 9 2023, 1:38 PM
Herald added a project: Restricted Project. · View Herald Transcript
Herald added a subscriber: ributzka. · View Herald Transcript
arphaman requested review of this revision.Jan 9 2023, 1:38 PM

I'm disturbed that the string-literal diagnostic you changed never shows up in the tests. I suspect this attribute needs significantly better test coverage.

clang/docs/LanguageExtensions.rst
4815 ↗(On Diff #487546)

Can you explain in here what the "USR" is here/means here? Or what said string is supposed to be?

4823 ↗(On Diff #487546)

__has_feature isn't really the right solution here. Though, we don't typically have a way to test for individual features of an attribute other than the value that __has_attribute returns. In standard attributes, it returns a larger number when new features are added (see SD-10's Feature Test Macros).

I don't think I want us using __has_feature here though, either a different value for __has_attribute might be OK, or alternatively, perhaps just a simple feature-test-macro.

clang/include/clang/Basic/AttrDocs.td
1754

This DEFINITELY needs to better explain what a USR is, and why one would use it. Many times this document is used by folks to discover attributes they didn't know existed, and this needs to be usable for someone who doesn't really get the context until reading this document.

clang/include/clang/Basic/DiagnosticCommonKinds.td
58

I don't think adding 'name' to these makes them particularly more readable? At least from what I can see reading it here.

arphaman updated this revision to Diff 487944.Jan 10 2023, 12:16 PM
arphaman marked 3 inline comments as done.

Updated to address review comments.

I'm disturbed that the string-literal diagnostic you changed never shows up in the tests. I suspect this attribute needs significantly better test coverage.

Please elaborate. All the diagnostics have appropriate coverage already.

clang/include/clang/Basic/DiagnosticCommonKinds.td
58

I did not add 'name' here, I moved it from the right hand side as I added a new clause that didn't use name.

I'm disturbed that the string-literal diagnostic you changed never shows up in the tests. I suspect this attribute needs significantly better test coverage.

Please elaborate. All the diagnostics have appropriate coverage already.

I'd mistakenly thought that you'd changed the message to add 'name', not moved it.

That said, test coverage of the new feature should be improved. I don't see anything about the contents of the USR, nor anything with the USR field being dependent.

clang/include/clang/Basic/DiagnosticCommonKinds.td
58

Ah! Thanks! I missed that.

bnbarham accepted this revision.Jan 10 2023, 1:37 PM

LGTM, thanks Alex!

This revision is now accepted and ready to land.Jan 10 2023, 1:37 PM
erichkeane requested changes to this revision.Jan 10 2023, 1:39 PM

Note both the Clang maintainer, and attributes maintainer have requested changes in some way, please let that finish before committing.

This revision now requires changes to proceed.Jan 10 2023, 1:39 PM
arphaman updated this revision to Diff 490214.Jan 18 2023, 9:58 AM

add more test coverage

@erichkeane I've added more test coverage with different USR values, C++ decls and some dependent C++ decls too. How does it look now?

erichkeane added inline comments.Jan 18 2023, 12:30 PM
clang/include/clang/Basic/AttrDocs.td
1755
1762
1764

I don't think we can do this. __has_attribute needs to take the actual name of the attribute.

aaron.ballman added inline comments.Jan 18 2023, 12:31 PM
clang/include/clang/Basic/AttrDocs.td
1764

+1

clang/lib/Basic/Attributes.cpp
30–32 ↗(On Diff #490214)

This is handled automagically for you in Attr.td, but under the correct attribute name instead of an invented name.

arphaman added inline comments.Jan 18 2023, 12:50 PM
clang/include/clang/Basic/AttrDocs.td
1764

__has_attribute(external_source_symbol) already works but it wouldn't help here as it doesn't tell whether the attribute supports USR or not. Are you saying I should come up with a totally new attribute that accepts USR? That was originally why I had the __has_feature check.

erichkeane added inline comments.Jan 18 2023, 12:54 PM
clang/include/clang/Basic/AttrDocs.td
1764

The typical way of doing this in the standard is to have has_c_attribute/has_cpp_attribute return a larger non-zero value for the normal attribute.

I suspect we should extend __has_attribute to do something similar (that is, allowing Feature Test Macros' for it). Aaron, WDYT?

aaron.ballman added inline comments.Jan 18 2023, 12:56 PM
clang/include/clang/Basic/AttrDocs.td
1764

The typical way of doing this in the standard is to have has_c_attribute/has_cpp_attribute return a larger non-zero value for the normal attribute.

Which we expose for the CXX11 and C2X spellings in Attr.td, but don't expose for the Clang spelling (easy enough to change).

I suspect we should extend __has_attribute to do something similar (that is, allowing Feature Test Macros' for it). Aaron, WDYT?

+1, if we don't already do that. This should be handled entirely within Attr.td and ClangAttrEmitter.cpp for a generic solution.

arphaman added inline comments.Jan 18 2023, 2:52 PM
clang/include/clang/Basic/AttrDocs.td
1764

sounds good, I will look into that and will update this patch.

arphaman updated this revision to Diff 490547.EditedJan 19 2023, 9:02 AM

Updated __has_attribute(external_source_symbol) to return a version.

erichkeane added inline comments.Jan 19 2023, 10:36 AM
clang/include/clang/Basic/Attr.td
962

For standards version numbers, we tend to set this to a 'date' more or less, so something like 20230119. I wonder if there is value to making THAT how we do this here too?

clang/utils/TableGen/ClangAttrEmitter.cpp
3327

Why is this =="Clang" specific? Since you've added the Version to the spelling, I'd anticipate us to just be able to grab it for the current spelling. I wouldn't want an individual spelling here to override it, particularly since with this change Clang could potentially override the standards version.

arphaman added inline comments.Jan 19 2023, 12:46 PM
clang/include/clang/Basic/Attr.td
962

That's a good idea, I can update it to be a specific date.

clang/utils/TableGen/ClangAttrEmitter.cpp
3327

I needed it since there's no specific "Clang" variety that's being called for this function. Otherwise the "GNU" variety passed to the function doesn't match "Clang" variety in the record. What's the best way to compute the current spelling in this case?

erichkeane added inline comments.Jan 19 2023, 12:49 PM
clang/utils/TableGen/ClangAttrEmitter.cpp
3327

Hmm... that is strange. I would have expected this to be called for each of the individual spellings, it doesn't really make sense that it wouldn't pick it up from the base 'Spellings'. I've unfortunately not debugged this code generation in a while. BUT, we care about the 'version' on a per-spelling basis, so it would presumably need to 'pick' an actual spelling.

aaron.ballman added inline comments.Jan 20 2023, 5:00 AM
clang/utils/TableGen/ClangAttrEmitter.cpp
3327

This does get called for each of the base spellings: https://github.com/llvm/llvm-project/blob/main/clang/utils/TableGen/ClangAttrEmitter.cpp#L3393

I think the issue is that, in Attr.td, the GNU spelling has no version information associated with it. I think what should happen is that spelling should get a Version field the same as CXX11 and C2X do, and the Clang spelling can pass that information along to the GNU spelling so that it gets picked up here during tablegen.

One thing we should probably be careful of is compatibility with GCC. I *think* GCC just returns 0 or 1 from __has_attribute but we should find out if they return specific values for any of the attributes we already support (a follow-up patch can correct those values so we match GCC if necessary).

arphaman added inline comments.Jan 20 2023, 1:43 PM
clang/utils/TableGen/ClangAttrEmitter.cpp
3327

I think the issue is that, in Attr.td, the GNU spelling has no version information associated with it. I think what should happen is that spelling should get a Version field the same as CXX11 and C2X do, and the Clang spelling can pass that information along to the GNU spelling so that it gets picked up here during tablegen.

I'm not sure I understand how Clang should pass that information to the GNU spelling. Here we already set Version in each spelling. Do you think "Clang" should inherit from "GNU" spelling in tablegen, e.g.:

class Clang<string name, bit allowInC = 1, int version = 1>
    : GNU<name, "Clang", version> {
  bit AllowInC = allowInC;
}
arphaman updated this revision to Diff 491865.Jan 24 2023, 11:48 AM

updated patch.

arphaman added inline comments.Jan 24 2023, 11:58 AM
clang/utils/TableGen/ClangAttrEmitter.cpp
3327

@aaron.ballman @erichkeane I updated this function to use FlattenedSpelling - now I don't have to check for "Clang" explicitly. How does it look now.

That part is Ok now, thanks. However, this still needs a release note, plus a test for spelling versions.

arphaman updated this revision to Diff 495165.Feb 6 2023, 9:34 AM
  • Updated version to be the date.
  • Updated release notes.
  • Fixed a bug in my changed tablegen code in previous patch.
arphaman updated this revision to Diff 495202.Feb 6 2023, 10:15 AM

updated test file with correct version check.

erichkeane accepted this revision.Feb 14 2023, 7:29 AM
This revision is now accepted and ready to land.Feb 14 2023, 7:29 AM
This revision was landed with ongoing or failed builds.Feb 23 2023, 2:59 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptFeb 23 2023, 2:59 PM