Patch to fix an invalid AST of a locally redeclared built-in which causes an IRGen crash

[Richard Smith]

On Thu, May 22, 2014 at 1:48 PM, jahanian <fjahanian at apple.com> wrote:

>
> On May 22, 2014, at 11:40 AM, Richard Smith <richard at metafoo.co.uk> wrote:
>
>
> Another problem with our current model is that we build a broken
> redeclaration chain (the local declaration is marked as being a
> redeclaration of the implicitly-declared builtin, which it isn't). This
> leads to other bugs; for instance:
>
> void f() { int memcpy(void); } void g() { memcpy(0,0,0); }
>
> ... misses the "implicitly declaring library function" warning.
>
>
> Interesting point. Currently, we create a built-in declaration of “memcpy”
> and make local declaration as its redeclaration.
> Should we just not create the implicit built-in declaration when user
> declaration is local? If we do this,
> then the missing  warning you mentioned will come out (and my bug gets
> fixed). But, we will miss the warning
> about "incompatible redeclaration of library function ‘memcpy’” on
> local “redeclaration”.
> Which, I think, is ok as it is no longer a redeclaration.
> Am I reading you correctly?
>

I think we should still produce the "incompatible redeclaration of library
function" warning. I think it'd be better if we didn't create the implicit
built-in declaration at all, but I don't think it should matter whether the
declaration is local. If I write a non-local declaration:

  int memcpy(void);

... I should not get a redecl chain for memcpy with two declarations with
different parameter types.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140522/fbd63024/attachment.html>