On Tue, Nov 1, 2016 at 11:45 AM, Bernd Edlinger <bernd.edlin...@hotmail.de> wrote: > On 11/01/16 16:20, Jason Merrill wrote: >> On 10/17/2016 03:18 PM, Bernd Edlinger wrote: >> I'm not even sure we need a new warning. Can we combine this warning >> with the block that currently follows? > > After 20 years of not having a warning on that, > an implicitly enabled warning would at least break lots of bogus > test cases.
Would it, though? Which test cases still break with the current patch? > Of course in C we have an implicitly enabled warning, > so I would like to at least enable the warning on -Wall, thus > -Wshadow is too weak IMO. Right. The -Wshadow warning is for file-local declarations, so that doesn't apply to your testcase; I was thinking that we should hit the first (currently unconditional) warning. >>> else if ((DECL_EXTERN_C_P (newdecl) >>> && DECL_EXTERN_C_P (olddecl)) >>> || compparms (TYPE_ARG_TYPES (TREE_TYPE (newdecl)), >>> TYPE_ARG_TYPES (TREE_TYPE (olddecl)))) So I was thinking to drop the "else" and the compparms test. >>> { >>> /* A near match; override the builtin. */ >>> >>> if (TREE_PUBLIC (newdecl)) >>> warning_at (DECL_SOURCE_LOCATION (newdecl), 0, >>> "new declaration %q#D ambiguates built-in " >>> "declaration %q#D", newdecl, olddecl); So we would hit this warning. And change the message to remove "ambiguates", since we're removing the compparms. > This started because I wanted to add builtin functions for some > special_function_p names. And I wanted to warn the user if he uses a > name that is recognized by special_function_p, but the parameters > don't match. Now I think we need to teach special_function_p to > distinguish "C" functions from "C++" functions, which it currently > cannot do, because that knowledge is only in the C++ FE. It could look at DECL_ASSEMBLER_NAME rather than DECL_NAME? Jason