<div dir="ltr">For a Type held by an AST node, I completely agree, and I'll try to address that.  For a type held by a TypeSourceInfo, I disagree, the FunctionProtoType should really hold the undecayed parameter types.<div>
<br></div><div>The problem is that we have lots of call sites where Sema pulls the type off of TSI and builds it into the AST.  I'll see if I can audit those.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Jun 11, 2013 at 5:24 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
  At a higher level, the big, potentially breaking change here is that you're making FunctionProtoType::getArgType() potentially return an undecayed type.  There are around 100 users of this API in-tree, and it looks like a substantial fraction of them are going to need a similar change.  I'm not comfortable with an API named getArgType() returning an un-decayed type; even if you catch all the existing cases which need additional checks, people writing new code aren't going to be thinking about this, and the un-decayed type is almost always the wrong answer from a semantic point of view.  Any APIs on FunctionProtoType returning un-decayed types should have "un-decayed" in the name, IMO.<br>

<br>
<a href="http://llvm-reviews.chandlerc.com/D957" target="_blank">http://llvm-reviews.chandlerc.com/D957</a><br>
</blockquote></div><br></div>