VerifyDiagnosticConsumer and ModuleMapParser
Vassil Vassilev
vasil.georgiev.vasilev at cern.ch
Mon Nov 10 06:52:41 PST 2014
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 <vvasilev at cern.ch> 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
>> cfe-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
More information about the cfe-commits
mailing list