Add type check for explicit instantiation of template classes' static data members. This is a bug fix for #38205.
The code of checks for variable templates is just before the additional code. But the conditions of if statement and the format of diagnostics are different, so it may be better to do the check for static member instantiation separately. And I have reused the type comparing function (with an argument different).
I'm guessing this function is pretty widely used - so this change might be a bit invasive/may not be what all callers want?
@rsmith - this is getting a bit out of my wheelhouse and I'd rather like you to take a look when you've got a chance
The ObjC comment seems a bit out of place here - since the code here doesn't seem to mention them. Maybe skip that part here, and leave it to be described up in the hasSameType function?
I assume this was already tested somewhere else, perhaps? (since your change was about static member variables of class templates, and didn't touch the existing code for variable templates) So probably doesn't need re-testing here.
In this update I delete some extra test code, move several comments and split the new type comparing code into a new function to make sure that the commonly used old type comparing function not affected by it.
Which? Do you mean the unit test? It seems to be irrelevant with this revision. This revision doesn't change the code covered by that test. The failure should be caused by other commit on the trunk.
Can we combine this with the previous if? This is really checking the same thing that the hasSameType check above checked.
The check of TSK seems unnecessary (and incorrect) here -- we should check the type is correct regardless of whether this is an explicit instantiation declaration or an explicit instantiation definition.
Please can you point us at an example that needs this "ignore lifetime" nuance? We should check with Apple folks what they want to happen here, and we should presumably have the same rule for all explicit instantiations of templated variables -- both in the static data member case here and the variable template case a few lines above.
My expectation is that we want one of these two rules:
(or a combination of these rules where we accept either option). I don't think that matches what you're doing here -- in particular, I think a wrong declared lifetime on the explicit instantiation should result in an error.