[PATCH,c++] fix PR 45330, suggest alternatives for failed name lookups

Gabriel Dos Reis gdr@integrable-solutions.net
Fri Dec 3 16:48:00 GMT 2010


On Fri, Dec 3, 2010 at 10:41 AM, Nathan Froyd <froydnj@codesourcery.com> wrote:
> On Fri, Dec 03, 2010 at 11:22:45AM +0100, Dodji Seketeli wrote:
>> Nathan Froyd <froydnj@codesourcery.com> writes:
>> > @@ -449,7 +449,10 @@ unqualified_name_lookup_error (tree name)
>> >    else
>> >      {
>> >        if (!objc_diagnose_private_ivar (name))
>> > -        error ("%qD was not declared in this scope", name);
>> > +   {
>> > +     error ("%qD was not declared in this scope", name);
>> > +     suggest_alternatives_for (name);
>> > +   }
>>
>> As we are gradually moving away from using the global input_location
>> variable for better diagnostics maybe suggest_alternative could take a
>> location parameter that ...
>>
>> > +void
>> > +suggest_alternatives_for (tree name)
>> > +{
>>
>> [...]
>>
>> > +  if (n_searched >= max_to_search)
>> > +    inform (input_location,
>> > +       "maximum limit of %d namespaces searched for %qE",
>> > +       max_to_search, name);
>>
>> ... would be used here instead of using the global input_location.
>>
>> OK, this really is a small nit. Sorry for the noise if it's
>> irrelevant.
>
> I think that's a good suggestion; I wasn't aware that we were trying to
> move away from input_location.
>
> One thing that really threw me from the diagnostics is that the C++
> language-specifier formatter can set the location of the message
> (error.c:cp_printer).  That seems a little weird--it would be better if
> the location were explicit at the point of the diagnostic, rather than
> arising from the things being printed.

It is far more involved than that.  Locations are also retrieved from
expressions.  What you are seeing is remains of history.

>
> I can do this pretty easily, but I think it will require unstatic'ing
> location_of from error.c as my patch for PR 45329 does.  It doesn't
> matter to me which goes in first; I suppose I can add the location_of
> bits to whichever one does.
>
> -Nathan
>



More information about the Gcc-patches mailing list