On Feb 3, 2014, at 2:32 PM, Ben Langmuir <[email protected]> wrote:
> Based on a suggestion from Jordan I’ve dropped the extra note, which will be
> on the same location anyway, and added that information into the error
> diagnostic. I would have liked to say "treating #include ...” instead of
> "treating directive …", but after the preprocessor/lexer this information is
> lost and I don’t see a nice way to pass it on to the parser.
There’s an ugly way to pass it on to the parser… you have a couple low bits in
the token’s annotation value to record #include vs. #import vs. #include_next.
+def err_import_in_impl : Error<
+ "%select{|treating directive as a module import; }0module import not allowed
"
+ "within @implementation">;
The diagnostic is pretty wordy when the import comes from a directive. Perhaps
this?
module import (due to #include) not allowed within @implementation
- Doug
> Ben
>
> <import-in-impl.patch>
>
>
> On Feb 3, 2014, at 10:19 AM, Ben Langmuir <[email protected]> wrote:
>
>> This patch disallows module import inside @implementaiton, and also moves
>> the parsing for implicit imports (e.g. #import) into the same function as
>> explicit imports (@import). Previously we silently accepted explicit
>> imports in @implementation, but gave a missing ‘@end’ error on implicit
>> imports.
>>
>> Ben
>>
>> <import-in-impl.patch>_______________________________________________
>> 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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
