It seems to me not a bad idea: if we are planning to provide better
diagnostics of 'ill-formed' modulemaps. We could use FileCheck but I
thought -verify was invented for such cases.
Vassil
On 11/07/2014 01:09 AM, Jordan Rose wrote:
Is it really worth putting effort into -verify for this? I'd be okay with just
using FileCheck:
// CHECK: {{Inputs[/\\]declare-use[/\\]module.map}}:30:10: note: header file...
Jordan
On Nov 3, 2014, at 2:10 , Vassil Vassilev <[email protected]> wrote:
Hi guys,
I am working on http://llvm.org/bugs/show_bug.cgi?id=20507 Now the diagnostic
gets issued for:
Clang :: Modules/declare-use1.cpp
Clang :: Modules/declare-use2.cpp
Clang :: Modules/declare-use3.cpp
Clang :: Modules/strict-decluse.cpp
It says smth like: Modules/Inputs/declare-use/module.map:30:10: note: Header
file 'unavailable.h' not present in module 'XF'
I'd like to add an expected diag to the modulemap file. Eg:
module XF {
...
header "unavailable.h" // expected-note {{...}}
...
}
Is that the right way to go?
If yes, VerifyDiagnosticConsumer requires some callbacks (such as
HandleComment) which come from the Preprocessor. In the ModuleMapParser we use
raw lexing (without PP at all) and I was wondering what would be the right way
to go, in order to make the -verify flag work inside the module maps. One
solution that I see is to pass the comment handlers from the PP to the
ModuleMapParser, however IMO this would break the encapsulation. Do you have
better ideas?
Many thanks,
Vassil
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
