This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Hi, The principle of Objective-c/c++ is that they should be supersets of the parent language. Thus, it is intended that valid c++ (or c) should be parsed by the relevant objective-c/c++ FE. While trying to build some external code, I found that lambdas confuse things at present for objcp. When we find "[" and we're in objcp mode, and the "[" introduces a lambda, we try to parse a message expression and if that fails we punt (thus we are unable to recognise lambdas). The attached patch tries "[" as a message expression introducer, if that fails it drops through to try for a lambda (no change intended for the non-objective-c++ path). I guess it's a bit of a nuisance that the diagnostics from a failed message expression are likely to end up as mentioning a lambda. Perhaps we might decide to punt early if we are both ObjC and < c++11. This allows me to parse some necessary lldb headers with gcc objcp. Thoughts / OK for trunk? (I can raise a formal PR if you like). Iain gcc/cp: * parser.c (cp_parser_primary_expression): If parsing an objective-c++ message expression fails, see if a lambda is present. (cp_parser_objc_message_reciever): Don't assume that if a message reciever expression fails it is a hard error. gcc/testsuite: * obj-c++.dg/lambda-0.mm New file. * obj-c++.dg/lambda-1.mm New file.
Attachment:
objcp-lambdas.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |