[cfe-dev] Is it safe to cast-away constness to use Clang static analysis?

John McCall via cfe-dev cfe-dev at lists.llvm.org
Wed Oct 4 11:40:47 PDT 2017


> On Oct 4, 2017, at 2:21 PM, Roman Popov <ripopov at gmail.com> wrote:
> In conclusion: 
> Should AST matchers should return non-const pointers to comply with Clang coding standard for immutable objects?

I think it is more likely than not that the Clang ASTs will gradually standardize on taking non-const pointers.  Given that AST matchers tend to create out-of-tree dependencies, I think it would be better for them to go ahead and work primarily with non-const pointers.

If you want to do some of the work to make the ASTs traffic in non-const pointers, that would be good, too, although we should first get consensus that that's the direction we want to go in.

John.

> 
> 2017-10-04 11:14 GMT-07:00 John McCall via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>:
> 
> > On Oct 4, 2017, at 3:30 AM, Csaba Raduly via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> >
> > On Wed, Oct 4, 2017 at 2:20 AM, John McCall via cfe-dev
> > <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> >>
> >> The AST is largely immutable by design, and the best solution would probably
> >> be to adopt what LLVM did to Type and just mass-refactor code to stop
> >> passing around const pointers at all.
> >
> > If the AST is meant to be immutable, why not pass const
> > {pointers,references} around?
> 
> If the objects are actually immutable, const is just noise repeated everywhere, because a non-const object is basically a useless type.
> 
> John.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20171004/afe86106/attachment.html>


More information about the cfe-dev mailing list