Abandoned this revision and folded the changes into another revision.

The false positives from this check are causing some disruption for XCTest framework users after some changes that we believe happened in Xcode 14. It would be nice if we could land some form of fix soon. I am happy to discuss options and iterate as needed.

Included namespace comment linter fixes from D137740 as advised by @Eugene.Zelenko,

In D137740#3918271, @Eugene.Zelenko wrote:

Will be good idea to combine this patch with D137738.

LGTM after fixing the assertion ✅

In D113616#3347980, @clayborg wrote:

Very easy change as VS Code IDE displays these strings and no one references these by name.

In D113616#3341803, @JDevlieghere wrote:

This seems trivial enough, but adding Greg as he wrote most of lldb-vscode.

Maybe ahatanak might be a good reviewer based on https://reviews.llvm.org/D112850?

Make sense to me.

Looks reasonable to me.

Looks good!

One last correction and I think that you're all set!

Looks in good shape 👌 A couple nits and polish ideas.

Thanks for the fix and for the confirmation! 👍

The changes look functionally safe.

Please let me know if there are any corrections that are required to the output of clang-tools-extra/clang-tidy/add_new_check.py.

(sorry for the delay 😅)

I wasn't sure what the policy is for renaming checks so I dug into previous check renames. https://reviews.llvm.org/D43867 seems to indicate that it's acceptable for checks to be renamed with documentation in the release notes (though there is some discussion about the possibility of recognizing the old check name for a grace period). Based on the aforementioned precedent I don't have concerns with this proposed change.

Looks good 👌

It looks like everything is in order. I will proceed with landing the patch on your behalf 👍

Does the check allow variables in anonymous namespaces?

namespace {
dispatch_once_t onceToken;
}

I think such variables should satisfy initialization requirements.

If not, can we update the check to not trigger on variables? Either way, can we add a test to verify behavior for variables in anonymous namespaces?

Looks good! A couple nits/questions.

Thanks for the review!

Restrict ojbc-missing-hash to Objective-C language variants and fix sorting of
release notes.

In D67567#1670144, @mwyman wrote:

In D67567#1670035, @lebedev.ri wrote:

In D67567#1670017, @mwyman wrote:

In D67567#1669866, @lebedev.ri wrote:

2. Is dispatch_once_t OSX-specific thing? Should those checks be in osx module?

2. I don't see an osx module—am I somehow missing seeing it?

One can be added.

dispatch_once_t is something from libdispatchwhich is an Apple-created API, but is OSS and available outside Apple. It's also a C API, which is why I didn't feel objc was an appropriate module either. I'm open to a better home module for this check, it's just not clear to me where that might be.

No opinion on my question, just thought it should be asked,

As Ben commented, I don't feel this should be in an osx module, as libdispatch is highly used on iOS and other Apple platforms. I know it's available elsewhere, but it may be so seldom used that I think a darwinmodule might be reasonable. I looked at the process for creating a new module, and can do that if we'd like, but should that be part of this same review?

Fix example matches in comment.

Use llvm::SmallPtrSet to store the compatible aliases instead of std::set.
Fix a stray unit test failure in RegistryTest.cpp.

Add tests for isDirectlyDerivedFrom.

Whoops; forgot to add test cases for isDirectlyDerivedFrom 🤦 Will do that shortly.

I spent some time becoming familiar with how isDerivedFrom behaves for C++ classes. I think that I have managed to get the behavior for Objective-C classes to mirror that of C++ classes. Please let me know if I overlooked anything.

Update isDerivedFrom to match aliased types and compatibility aliases of
derived Objective-C classes.

I think your changeset caused a failure in this buildbot.
http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/18933
Failure : http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/18933/steps/ninja%20check%201/logs/stdio

Thanks for the input! I will get started on making changes accordingly.

It looks like all concerns have been addressed. Do you need me to land this commit for you?