<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, 9 Jul 2018 at 14:06, Stephen Kelly via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Stephen Kelly via cfe-dev wrote:<br>
<br>
> 1) DeclarationNameInfo has both getLocEnd and getEndLoc. Both are used by<br>
> calling code, and I can't tell if any use is incorrect. At any rate, if<br>
> the two methods are to remain, the getLocEnd() one should be renamed to<br>
> something more specific as it is the one doing something different to<br>
> other getLocEnd/getEndLoc methods which generally don't 'try again' in the<br>
> invalid case.<br>
<br>
I created a patch to inline getLocEnd() into callers.<br>
<br>
 <a href="https://reviews.llvm.org/D49100" rel="noreferrer" target="_blank">https://reviews.llvm.org/D49100</a></blockquote><div><br></div><div>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()).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> <snip><br>
> Is that something we would really want to do? I value consistency, but<br>
> breaking all Clang API users so dramatically is something to do only if it<br>
> is seen as valuable to a consensus of the community.<br>
<br>
This is still pending discussion of some sort.<br></blockquote><div><br></div><div>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.</div></div></div>