[cfe-commits] r159464 - in /cfe/trunk: lib/Sema/SemaDecl.cpp test/SemaCXX/typo-correction.cpp

[Kaelyn Uhrain]

On Fri, Jun 29, 2012 at 2:36 PM, David Blaikie <dblaikie at gmail.com> wrote:

> On Fri, Jun 29, 2012 at 2:30 PM, Kaelyn Uhrain <rikka at google.com> wrote:
> > Author: rikka
> > Date: Fri Jun 29 16:30:39 2012
> > New Revision: 159464
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=159464&view=rev
> > Log:
> > In Sema::ClassifyName, try to avoid nonsensical corrections to
> > keywords when doing type correction.
> >
> > Modified:
> >    cfe/trunk/lib/Sema/SemaDecl.cpp
> >    cfe/trunk/test/SemaCXX/typo-correction.cpp
> >
> > Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=159464&r1=159463&r2=159464&view=diff
> >
> ==============================================================================
> > --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
> > +++ cfe/trunk/lib/Sema/SemaDecl.cpp Fri Jun 29 16:30:39 2012
> > @@ -634,6 +634,19 @@
> >     if (!SecondTry) {
> >       SecondTry = true;
> >       CorrectionCandidateCallback DefaultValidator;
> > +      // Try to limit which sets of keywords should be included in typo
> > +      // correction based on what the next token is.
> > +      DefaultValidator.WantTypeSpecifiers =
> > +          NextToken.is(tok::l_paren) || NextToken.is(tok::less) ||
> > +          NextToken.is(tok::identifier) || NextToken.is(tok::star) ||
> > +          NextToken.is(tok::amp) || NextToken.is(tok::l_square);
> > +      DefaultValidator.WantExpressionKeywords =
> > +          NextToken.is(tok::l_paren) || NextToken.is(tok::identifier) ||
> > +          NextToken.is(tok::arrow) || NextToken.is(tok::period);
> > +      DefaultValidator.WantRemainingKeywords =
> > +          NextToken.is(tok::l_paren) || NextToken.is(tok::semi) ||
> > +          NextToken.is(tok::identifier) || NextToken.is(tok::l_brace);
> > +      DefaultValidator.WantCXXNamedCasts = false;
> >       if (TypoCorrection Corrected =
> CorrectTypo(Result.getLookupNameInfo(),
> >                                                  Result.getLookupKind(),
> S,
> >                                                  &SS, DefaultValidator))
> {
> >
> > Modified: cfe/trunk/test/SemaCXX/typo-correction.cpp
> > URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/typo-correction.cpp?rev=159464&r1=159463&r2=159464&view=diff
> >
> ==============================================================================
> > --- cfe/trunk/test/SemaCXX/typo-correction.cpp (original)
> > +++ cfe/trunk/test/SemaCXX/typo-correction.cpp Fri Jun 29 16:30:39 2012
> > @@ -227,3 +227,10 @@
> >  // 'boo' to 'bool' is the same edit distance as correcting 'boo' to
> 'foo'.
> >  class bar : boo { }; // expected-error{{unknown class name 'boo'; did
> you mean 'foo'?}}
> >  }
> > +
> > +namespace bogus_keyword_suggestion {
> > +void test() {
>
> Would it make sense to have this test case have a reasonable return
> type for the code/return statement in its body? Or you can leave it as
> is & someone else can change it if the diagnostic/recovery gets
> further improvements in this area.
>

Ah, yes... the test case is copied straight from the internal bug that Nick
filed, so I missed that. I'm torn, but I think it might be better to leave
it as is as a test case related to future diagnostic improvements in this
area... such as if that 'status = "OK";' were to be recovered as 'auto
status = "OK";' as an instance where that recovery would more likely be
incorrect, i.e. the function was refactored to no longer return the status
and that assignment and return statement were missed, or if they were part
of a block of code copied and pasted from a function that did return a
value. ;)  But I can go either way with whether to change the function
return type to be something sensible.

>
> > +   status = "OK"; // expected-error-re{{use of undeclared identifier
> 'status'$}}
>
> Would it be completely silly to recover as if the user wrote "auto x =
> y;" whenever we see "x = y;" with x being undeclared? (we don't
> necessarily have to suggest it as a fixit, but might make for a better
> recovery than assumed int or not adding this to the symbol table at
> all)
>
> - David
>
> > +   return status; // expected-error-re{{use of undeclared identifier
> 'status'$}}
> > + }
> > +}
> >
> >
> > _______________________________________________
> > cfe-commits mailing list
> > cfe-commits at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120629/3b3256a2/attachment.html>