llvm-project/clang/test/PCH/typo.m

// RUN: %clang_cc1 -x objective-c-header -emit-pch -o %t %S/Inputs/typo.h
// RUN: %clang_cc1 -include-pch %t -verify %s

void f() {
  [NSstring alloc]; // expected-error{{unknown receiver 'NSstring'; did you mean 'NSString'?}}
                    // expected-note@Inputs/typo.h:3{{declared here}}
}
When performing typo correction, look through the set of known identifiers to determine good typo-correction candidates. Once we've identified those candidates, we perform name lookup on each of them and the consider the results. This optimization makes typo correction > 2x faster on a benchmark example using a single typo (NSstring) in a tiny file that includes Cocoa.h from a precompiled header, since we are deserializing far less information now during typo correction. There is a semantic change here, which is interesting. The presence of a similarly-named entity that is not visible can now affect typo correction. This is both good (you won't get weird corrections if the thing you wanted isn't in scope) and bad (you won't get good corrections if there is a similarly-named-but-completely-unrelated thing). Time will tell whether it was a good choice or not. llvm-svn: 116528 2010-10-15 06:11:03 +08:00			`// RUN: %clang_cc1 -x objective-c-header -emit-pch -o %t %S/Inputs/typo.h`
			`// RUN: %clang_cc1 -include-pch %t -verify %s`
Extended VerifyDiagnosticConsumer to also verify source file for diagnostic. VerifyDiagnosticConsumer previously would not check that the diagnostic and its matching directive referenced the same source file. Common practice was to create directives that referenced other files but only by line number, and this led to problems such as when the file containing the directive didn't have enough lines to match the location of the diagnostic in the other file, leading to bizarre file formatting and other oddities. This patch causes VerifyDiagnosticConsumer to match source files as well as line numbers. Therefore, a new syntax is made available for directives, for example: // expected-error@file:line {{diagnostic message}} This extends the @line feature where "file" is the file where the diagnostic is generated. The @line syntax is still available and uses the current file for the diagnostic. "file" can be specified either as a relative or absolute path - although the latter has less usefulness, I think! The #include search paths will be used to locate the file and if it is not found an error will be generated. The new check is not optional: if the directive is in a different file to the diagnostic, the file must be specified. Therefore, a number of test-cases have been updated with regard to this. This closes out PR15613. llvm-svn: 179677 2013-04-17 16:06:46 +08:00
When performing typo correction, look through the set of known identifiers to determine good typo-correction candidates. Once we've identified those candidates, we perform name lookup on each of them and the consider the results. This optimization makes typo correction > 2x faster on a benchmark example using a single typo (NSstring) in a tiny file that includes Cocoa.h from a precompiled header, since we are deserializing far less information now during typo correction. There is a semantic change here, which is interesting. The presence of a similarly-named entity that is not visible can now affect typo correction. This is both good (you won't get weird corrections if the thing you wanted isn't in scope) and bad (you won't get good corrections if there is a similarly-named-but-completely-unrelated thing). Time will tell whether it was a good choice or not. llvm-svn: 116528 2010-10-15 06:11:03 +08:00			`void f() {`
			`[NSstring alloc]; // expected-error{{unknown receiver 'NSstring'; did you mean 'NSString'?}}`
Extended VerifyDiagnosticConsumer to also verify source file for diagnostic. VerifyDiagnosticConsumer previously would not check that the diagnostic and its matching directive referenced the same source file. Common practice was to create directives that referenced other files but only by line number, and this led to problems such as when the file containing the directive didn't have enough lines to match the location of the diagnostic in the other file, leading to bizarre file formatting and other oddities. This patch causes VerifyDiagnosticConsumer to match source files as well as line numbers. Therefore, a new syntax is made available for directives, for example: // expected-error@file:line {{diagnostic message}} This extends the @line feature where "file" is the file where the diagnostic is generated. The @line syntax is still available and uses the current file for the diagnostic. "file" can be specified either as a relative or absolute path - although the latter has less usefulness, I think! The #include search paths will be used to locate the file and if it is not found an error will be generated. The new check is not optional: if the directive is in a different file to the diagnostic, the file must be specified. Therefore, a number of test-cases have been updated with regard to this. This closes out PR15613. llvm-svn: 179677 2013-04-17 16:06:46 +08:00			`// expected-note@Inputs/typo.h:3{{declared here}}`
When performing typo correction, look through the set of known identifiers to determine good typo-correction candidates. Once we've identified those candidates, we perform name lookup on each of them and the consider the results. This optimization makes typo correction > 2x faster on a benchmark example using a single typo (NSstring) in a tiny file that includes Cocoa.h from a precompiled header, since we are deserializing far less information now during typo correction. There is a semantic change here, which is interesting. The presence of a similarly-named entity that is not visible can now affect typo correction. This is both good (you won't get weird corrections if the thing you wanted isn't in scope) and bad (you won't get good corrections if there is a similarly-named-but-completely-unrelated thing). Time will tell whether it was a good choice or not. llvm-svn: 116528 2010-10-15 06:11:03 +08:00			`}`