<div dir="ltr"><br><div>This does indeed look very familiar.  I would love it if clang had a pluggable type system.  It's been a while since I last looked at the issues, but I ran into two big problems, and ended up deciding that the amount of work was too large for me to tackle. </div><div><br></div><div>(1) Templates</div><div><br></div><div>As Doug mentioned, a major goal of pluggable types is to support the type erasure property; if you erase all of the pluggable attributes (perhaps using #define to eliminate them), then the behavior of the program should not change.  However, erasure and templates don't mix well.  For example std::vector<int*>  and  std::vector<__nonnull int*>  must have the same instantiation, because the canonical type is the same.  However, the two types must still be distinguished for the purpose of type checking.</div><div><br></div><div>In addition, type-checking of templatized code may produce errors for one attributed type (e.g. __nonnull int*), while having no errors in a type with a different attribute (e.g. int*).  However, we only instantiated the template once, with the canonical type.  Thus, we can either choose to (a) not produce errors in template code, or (b) try to type-check every template instantiation for all non-canonical variations in the template parameters, which may be infeasible.</div><div><br></div><div><br></div><div>(2) Dependent types</div><div><br></div><div>For thread safety analysis, my goal was to support dependent type attributes, e.g.</div><div><br></div><div>  void processAll(Mutex* mu, std::vector<int GUARDED_BY(mu)>& array) { ... }</div><div><br></div><div>Notice here that the type of 'array' depends on 'mu'.  This adds an additional wrinkle, especially when combined with (1), because you have to be extra careful about how you handle lexical scopes during template instantiation.</div><div><br></div><div>However, if these two problems were solved, then I could significantly improve the precision of thread safety analysis.</div><div><br></div><div>  -DeLesley</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Mar 15, 2015 at 4:58 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><p dir="ltr"><br>
On Mar 15, 2015 3:55 PM, "Adrian Sampson" <<a href="mailto:asampson@cs.washington.edu" target="_blank">asampson@cs.washington.edu</a>> wrote:<br>
><br>
> >> * Based on your discussion of type system impact, I'm sure you are all well aware that the compiler support for "maintaining type sugar through semantic analysis" needed to make this proposal work is *almost* enough to support a full "plug-able type system" similar to what's available in recent versions of Java. Do you have any plans to address the missing pieces? Being able to support pluggable type information more broadly (while continuing to guarantee that adding such qualifiers/attributes/however-it's-expressed would have zero impact on generated code) would enable all sorts of interesting analyses. A few examples that spring to mind include compile-time enforcement of physical unit compatibility, various protocol-level checks (type states, a la Bierhoff & Aldrich), and many more. When last I investigated this question (about a year ago), the limitation regarding templates (your [6]) was the only significant missing piece. Closing that gap would greatly reduce the difficulty (and project risk) of implementing such analyses.<br>
> ><br>
> > We’re almost there in Clang, although I doubt that I personally will have time any time soon to work on addressing the issue of type sugar flowing through template specializations. I don’t think it’s fundamentally that hard to do, and beyond that I expect that we’ll see a long tail of small issues where we’re not maintaining type sugar everywhere.<br>
><br>
> I’ve been working on a very hacky implementation of pluggable types for Clang. In fact, one of the prototypes I developed for the system is a simple nullability qualifier. There’s a little more detail on my blog:<br>
> <a href="http://homes.cs.washington.edu/~asampson/blog/quala.html" target="_blank">http://homes.cs.washington.edu/~asampson/blog/quala.html</a><br>
> <a href="http://homes.cs.washington.edu/~asampson/blog/quala-codegen.html" target="_blank">http://homes.cs.washington.edu/~asampson/blog/quala-codegen.html</a><br>
><br>
> So I’m very interested in generalizing mechanisms like what’s proposed here for __nonnull. This may be more straightforward to implement once __nonnull itself has landed. (At the very least, it should pave the way for my project’s patch to be smaller.) If anyone else is interested, let’s talk and perhaps put together a proposal.</p>
</div></div><p dir="ltr">Delesley - this is alls sounding a but familiar?</p><div class="HOEnZb"><div class="h5">
<p dir="ltr">><br>
> Adrian Sampson<br>
> University of Washington<br>
><br>
><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</p>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">DeLesley Hutchins | Software Engineer | <a href="mailto:delesley@google.com" target="_blank">delesley@google.com</a> | 505-206-0315<br></div>
</div>