Address comments.

The template specialization information is still available but we may need to print it by ourselves.
I will add a FIXME there and we will deal with it in a follow-up patch.

Current tests are mostly fine except that some notes with message "in instantiation of ... " are missing. Although these notes are not emitted by our analysis, we better understand why things change.

This sounds familiar, I think @usama54321 ran into a similar problem from inside clang-tidy: https://discourse.llvm.org/t/clang-tidy-diagnostics-for-template-code/62909

Address comments

Address comments

I have one general question: suppose we have two variables A and B in the same group. So fix-its emitted for A includes fix-its for B and vice verse, right? Does it mean that we cannot apply all fix-its at once from the command line?

Address comments

Rebased and addressed comments.

Thanks for the valuable discussion about the philosophy on the ideal forms of fix-its. In this case, I think &DRE.data()[any] and (DRE.data() + any) are both straightforward enough for the user to tell what has been changed and why we change that. And I believe both forms are idiomatic so that the user are likely happy with the form. I will keep this discussion in mind as we have other cases whose fix-its may be less idiomatic, such as D144304.

Still work in progress (but comments are very welcomed) ---there are several problems need to be solved:

• To conservatively detect any overload of the function whose parameter is being fixed. Thus far, the analysis cannot see any overload declared after the analyzing function.
• Fix-its conflict. Insertions of #include<span> and [[clang::unsafe_buffer_usage]] can conflict if both are inserted at the beginning of a file.
• There are many unsupported cases.
• Do we really want to fix parameters one at a time?
• As the fix-its become more complicated, tests now are harder to read.

Taking care of this patch on behalf of @jkorous

Address some of the comments.
Add handling for both *(ptr + n) and *(n + ptr).
Add handling for *((..(ptr + n) .. )
Remove the white space handling

Taking care of this revision on behalf of @jkorous

Addressing comments

Taking care of this patch on behalf of @jkorous.

Now we have different FixableGadgets that may match the same Stmt (representing a context).
So in order to discover all "Fixable"s, we can no longer match anyOf FixableGadgets' matchers. Instead, we match eachOf them.

Rebased.

Rebased

Let fixUPCAddressofArraySubscriptWithSpan return std::nullopt instead of an empty list when we should give up on the fix-it.

In D143128#4108375, @NoQ wrote:

Why do we prefer DRE.data() + any to &DRE.data()[any]? It could be much less intrusive this way, and the safety guarantees are the same.

To avoid emitting incorrect fix-its for array subscripts on span objects:

• For unsafe operations of the form s[e] where s is being transformed to be a span, we only emit fix-its for s[e] when e is a non-negative integer literal or e has an unsigned integer type.

Fixed a bug in manipulating source locations:

Change the fix-it test style

address comments

rebase

To attach fix-its to notes instead of warnings.
Fix the ending '\0' issue raised by @jkorous

Rebase the change

Addressing comments

Put the implementation of the opt-out pragma completely in Preprocessor.
Add an opt-out pragma test for fix-its.

Addressed the minor comments

Refactored the fix-it generation code to stop using the pretty-printer.

Rebased the code w.r.t. a series of refactoring in [-Wunsafe-buffer-usage].
Added a FixableGadget for array subscripts of the form DRE[*] in the context of lvalue-to-rvalue casting.