On Mon, Jun 8, 2015 at 7:31 AM, Andrey Bokhanko <[email protected]> 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*.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
