Disable google-readability-casting as it is broken.

[chandlerc]

I had been bothered by the confusing suggestions to replace calls to a constructor with ... calls to a constructor, claiming the original code was a C-style cast. In some code, we've worked around this by using static_cast but that really doesn't seem to be a readability win.

I did some research and from what I can tell this tidy check is deeply broken, with both Chromium and internal Google users disabling it due to widespread issues:
https://chromium.googlesource.com/chromium/src/+/f828a2248f0da4e7bfadfa5db324230043aaea02

We should disable it as well for now. I've removed one NOLINT comment for it, but not tried to remove all the static_casts that are now unnecessary as that seems hard to do in any automatic way.

Replace this paragraph with a description of what this PR is changing or
adding, and why.

Closes #ISSUE

[jonmeow]

We should disable it as well for now. I've removed one NOLINT comment for it, but not tried to remove all the static_casts that are now unnecessary as that seems hard to do in any automatic way.

Isn't this tidy check only warning about C-style casts? i.e., from a style perspective, doesn't Google's casting style still apply? If there are false positives for constructors, that would change. But we would still frequently be casting due to things like int vs size_t comparisons (which are probably the most frequent case). As a consequence, static_cast would remain. I see the one false positive here, but aren't the other uses of static_cast [ed: and reinterpret_cast, const_cast] correct?

That is to say, we have the occasional false positive, but also we use C++ casts a lot. If someone unfamiliar with Google C++ style comes along and starts adding C-style casts, is it going to be a net improvement if we're correcting the style in review? Should style change to instead encourage C-style casts?

[jonmeow]

If we're moving forward with this, is there an issue you can link to?

[jonmeow]

Note, the way you're talking about this issue is pretty strong. Would it be worth softening up the wording for other readers? e.g., maybe we could focus on the issue as it affects us:

Suggested change

	# - google-readability-casting is deeply broken, and fires regularly on calls
	# to constructors. Worse, it suggests switching to a call to a constructor
	# which doesn't fix the warning. This has been disabled by many major users
	# of clang-tidy (Chromium, etc).
	# - google-readability-casting fires regularly on calls to constructors. It suggests switching to a call to a constructor, which doesn't fix the warning.

[jonmeow]

Note too, you might also consider rephrasing the PR title and description.

[jonmeow]

I should also ask here, is this also an issue with {} constructor syntax? What's the code that you were trying to write that you ran into this?

[ed: to be sure -- it's not clear to me from https://crbug.com/1282228 whether they considered brace-based init as a possible solution]

[chandlerc]

Well, after a huge debugging session that should have been much shorter (Jon told me exactly what command I should run to confirm my assumption, and I took way to long to run it), I understand the issue better now.

There was some bug at some point or in some patched versions of clang-tidy and clangd here. But the reason there are few references to it any more is that these bugs got fixed. And in fact modern clang-tidy and clangd are completely correct here.

At some point, I was sure there weren't other versions of clangd available on macOS, but if that was true once, it isn't true now -- there is a version shipped in Xcode that VSCode knew how to find and has the specific bug in this check I was seeing. Anyways, I'm using the right version and we can delete this PR. I'll see abotu adding an FAQ entry about accidentally getting the wrong clangd in your IDE.

[zygoloid]

I'm still seeing problems with this check in our CI. Should we disable the check?