[cfe-dev] getLocStart versus getStartLoc

[Richard Smith via cfe-dev]

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? 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()).

> <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180720/d888db61/attachment.html>