VerifyDiagnosticConsumer and ModuleMapParser
Richard Smith
richard at metafoo.co.uk
Wed Nov 12 20:26:39 PST 2014
On Mon, Nov 10, 2014 at 6:52 AM, Vassil Vassilev <
vasil.georgiev.vasilev at cern.ch> wrote:
> 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.
I agree. We currently have essentially zero test coverage for our handling
of ill-formed module map files.
>
> 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
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141112/ee1def27/attachment.html>
More information about the cfe-commits
mailing list