Page MenuHomePhabricator

Compile and run objc tests in TestObjCBuiltinTypes.py as objc instead of c++.
AbandonedPublic

Authored by dawn on Jul 13 2015, 9:24 PM.

Details

Summary

The tests in TestObjCBuiltinTypes.py were compiled as C++ which didn't properly define the builtin ObjC type 'id' and caused the DWARF to claim the language was C++ instead of ObjC. As a result, when the language in lldb is set to C++ as read from the DWARF, the test would fail. This fix is a prerequisite to recognizing the language from the DWARF and setting the compiler options accordingly.

Diff Detail

Repository
rL LLVM

Event Timeline

dawn updated this revision to Diff 29641.Jul 13 2015, 9:24 PM
dawn retitled this revision from to Compile and run objc tests in TestObjCBuiltinTypes.py as objc instead of c++..
dawn updated this object.
dawn added reviewers: spyffe, clayborg, granata.enrico.
dawn set the repository for this revision to rL LLVM.
dawn added a subscriber: lldb-commits.
clayborg resigned from this revision.Jul 15 2015, 10:30 AM
clayborg removed a reviewer: clayborg.

Sean wrote most of this test so I will defer to him on this.

dawn added a comment.EditedJul 15 2015, 10:40 AM

Sean, please review? Thanks.

Added more reviewers in the hopes that someone will review this patch. Please?

spyffe edited edge metadata.Jul 20 2015, 11:13 AM

This looks like it's actually testing the wrong thing… the point is that the expression parser is in ObjC++ mode at all times and we want to make sure that we aren't misinterpreting something that happens to have the name "id" from C++ as something that's an ObjC id.

I'm concerned about the implicit suggestion that we not be in ObjC++ mode at all times. Specifically, it should be possible to run [NSApplication sharedApplication] wherever I'm stopped in an app. I would only want to turn the ObjC parts completely off if there were no Objective-C at all in the program; is this something we're planning on checking?

BTW, the reverse (no C++ if you're not in C++ mode) is going to be a lot trickier because the expression parser uses reference types internally.

dawn abandoned this revision.Jul 20 2015, 10:35 PM

This looks like it's actually testing the wrong thing… the point is that the expression parser is in ObjC++ mode at all times and we want to make sure that we aren't misinterpreting something that happens to have the name "id" from C++ as something that's an ObjC id.

I see.

I'm concerned about the implicit suggestion that we not be in ObjC++ mode at all times.

I ran into this when I wanted to have the default language be that of the selected frame, but folks prefer an option for that, so this test case will still work as is.

Thanks for your review.