<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 14 August 2013 07:45, Abramo Bagnara <span dir="ltr"><<a href="mailto:abramo.bagnara@gmail.com" target="_blank">abramo.bagnara@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Il 14/08/2013 00:30, Douglas Gregor ha scritto:<br>
<div class="im">><br>
> On Aug 13, 2013, at 3:08 AM, Pavel Labath <<a href="mailto:labath@google.com">labath@google.com</a><br>
</div><div><div class="h5">> <mailto:<a href="mailto:labath@google.com">labath@google.com</a>>> wrote:<br>
><br>
>> Greetings,<br>
>><br>
>> I have encountered a bug in the static analyzer<br>
>> <<a href="http://llvm.org/bugs/show_bug.cgi?id=16745" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=16745</a>>, which I have traced back<br>
>> to a problem with a synthesized operator=(). In short, the analyzer<br>
>> currently assumes that each expression object occurs in a function<br>
>> only once, and this breaks down for synthesized functions, as Sema<br>
>> happily reuses various Exprs there.<br>
>><br>
>> So, now the question is how to proceed. One possible solution (one<br>
>> that Jordan suggests) would be to have Sema not reuse any Exprs during<br>
>> synthesis of various functions. This should be fairly easy, but it<br>
>> will touch a larger amount of code (as the synthesis algorithm is<br>
>> recursive, I would need to pass some sort of expression factory<br>
>> objects instead of plain Expr *s back and forth). It would also make<br>
>> the code look less pretty and cause (probably only slight) memory<br>
>> increase.<br>
>><br>
>> Because of these downsides, I am not sure if a change like this would<br>
>> be accepted into the tree. Therefore, I wanted to ask you what do you<br>
>> think about this change before I invest time into carrying it out.<br>
>> Would you accept a patch like this? Or should i try to fix the problem<br>
>> from the analyzer side (right now I think it's doable, but it's quite<br>
>> possible i'll run into unexpected troubles)? Also, can you think of<br>
>> any other situations where sharing expression objects could cause<br>
>> troubles (template instantiations have been mentioned, but these<br>
>> should be fine as they don't produce nodes in the same function)?<br>
><br>
> I think it’s fine to teach Sema to build unique expressions within its<br>
> synthesized assignment operators. It’s a cleaner model for the AST anyway.<br></div></div></blockquote><div> </div><div>Ok, I'll get on it then.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5">
<br>
</div></div>Is this *in general* a viable approach?<br>
<br>
I'm thinking to repeated initializer in InitListExpr (as long as we need<br>
to put in AST the expanded nodes).<br></blockquote><div><br></div><div>Could you please elaborate on that? I'm not sure what you mean by repeated initializers. Do you know of a situation where an AST node can be present in the tree twice?</div>
<div><br></div><div>pl</div></div></div></div>