uecker wrote: > > > > Note that this confusion in principle applies to any use of any > > > > identifier, not just constants but also others in sizeof / typeof. > > > > > > > > > It does, but I think `-Wshadow` is the general purpose diagnostic used to > > > find those kinds of potential naming surprises. > > > I see the purpose to this diagnostic as being more specific to situations > > > where potential changes to lookup rules (allowing for late parsing of > > > function parameter names) might cause behavioral changes for users. But I > > > can see why that might be too narrow of a focus. > > > Where do you see the line being drawn between the two given that they're > > > related? > > > > > > I don't know. I hope we never see such breaking changes. If make breaking > > changes, the exact warning would depend on the exact nature of the changes. > > But I also think the need for the warning already shows that changing the > > lookup rules is a bad idea. > > FWIW, `-Wshadow` already warns about all these cases.
I think the existing -Wshadow is basically useless and I am not sure who even uses it. I think the model to look at would be GCC's -Wchanges-meaning which warns about the only similar case I know of, which is in C++ where use before redeclaration as a class member is IFNDR: https://godbolt.org/z/ee8KejbGa > > That said, I think adding a specific flag for array parameters would be > valuable because those are the specific scenarios we want to explore as > potential constraint violations, with the possibility of changing the > behavior in the future. > > @AaronBallman By the way, should the name be something like > `-Wshadow-array-parameter-potential-size-confusion` since we're also covering > const sizes? https://github.com/llvm/llvm-project/pull/181550 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
