[cfe-dev] getLocStart versus getStartLoc

[Stephen Kelly via cfe-dev]

Richard Smith via cfe-dev wrote:

> On Mon, 9 Jul 2018 at 14:06, Stephen Kelly via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
> 
>> Stephen Kelly via cfe-dev wrote:
>>
>> > 1) DeclarationNameInfo has both getLocEnd and getEndLoc. Both are used
>> > by calling code, and I can't tell if any use is incorrect. At any rate,
>> > if the two methods are to remain, the getLocEnd() one should be renamed
>> > to something more specific as it is the one doing something different
>> > to other getLocEnd/getEndLoc methods which generally don't 'try again'
>> > in
>> the
>> > invalid case.
>>
>> I created a patch to inline getLocEnd() into callers.
>>
>>  https://reviews.llvm.org/D49100
> 
> 
> Does the "start is valid but end is not" case ever actually happen?

I don't know.

> If so,
> fixing getEndLoc to always return a valid location seems like the right
> thing. We don't want getSourceRange() to ever return something different
> from SourceRange(getStartLoc(), getEndLoc()).

Yes, I started out trying to make a NFC change, but I came to the same 
conclusion as you a while ago without the time to change the approach. I've 
updated the Phab review now.

>> <snip>
>> > Is that something we would really want to do? I value consistency, but
>> > breaking all Clang API users so dramatically is something to do only if
>> it
>> > is seen as valuable to a consensus of the community.
>>
>> This is still pending discussion of some sort.
>>
> 
> We have historically taken the position that the churn caused for
> out-of-tree users of the C++ API are not a consideration when performing
> an API refactoring. (For two reasons: one is that we explicitly do not
> have a stable C++ API; the other is that this is the mechanism by which we
> encourage people to upstream changes.) This actually seems like a
> relatively easy change in that regard: client code can be largely updated
> by a regular expression.

Great, I'll look into doing this in a bit.

Thanks,

Stephen.