[PATCH] PR5172: Fix for a bug in pragma redefine_extname implementation.

[Richard Smith]

On Mon, Jun 8, 2015 at 7:31 AM, Andrey Bokhanko <andreybokhanko at gmail.com>
wrote:

> In http://reviews.llvm.org/D10187#184399, @rsmith wrote:
>
> > I think the right way to handle this would be to filter out declarations
> that are neither `FunctionDecl`s nor `VarDecl`s after performing the
> lookup. (According to the specification, we should also filter out
> declarations with internal linkage.)
>
>
> OK -- I did as you suggested. Please review updated patch.


That looks fine (although perhaps keep the creation of the attribute
outside the `if` so you don't need to duplicate it in both arms).

> We should also filter out internal-linkage declarations and non-TU-scope
> declarations when we perform the deferred handling of
> `ExtnameUndeclaredIdentifiers` in `ActOnVariableDeclarator` and
> `ActOnFunctionDeclarator`.
>
>
> This probably belongs to a separate patch (for starters, I don't have a
> test demonstrating that compiler is currently acting incorrectly).


That sounds fine. Here's a trivial testcase (it's easy to cook up more, the
bug is quite blatant):

#pragma redefine_extname foo bar
int f() {
  int foo = 0;
  return foo;
}
int foo() { return 1; }

The redefine_extname gets applied to the local variable 'foo', and the
global function 'foo' does not get renamed.

> That said, I'm not sure why your testcase was failing --
> `LookupSingleName` in `LookupOrdinaryName` mode in C should not find tag
> names, so we should have deferred adding the attribute already. Is a
> `typedef` missing from the testcase, perhaps?
>
>
> You mean modifying it like this:
>
> typedef struct {
>
>   int f;
>
> } statvfs64;
>
> ?
>
> Then compiler issue an error: "redefine_extname.c:10:5: error:
> redefinition of 'statvfs64' as different kind of symbol". No errors are
> issued in the original test.


Your current test passes for me without your patch, so you need to change
it *somehow*.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150608/e4a50dde/attachment.html>