More sensible ObjC handling in cpplib.

[Stan Shebs]

Neil Booth wrote:
> 
> When looking to remove most of the remaining alpha/ specs, most of which
> are based on the choice of language, I noticed that we don't seem to be
> handling ObjC intelligently as a language selector in cpplib.
> 
> IMO, "-std=c99 -lang-objc" and "-lang-objc -std=c99" should both give
> the C99 standard with ObjC extensions (namely, @ strings).  However,
> with the current implementation the former gives C89 ObjC, and the latter
> C99 with no ObjC, because they are considered mutually exclusive, and
> the latter wins.
> 
> Similarly for when ObjC++ appears, IMO ObjC-ness should be an
> "additionally-ObjC" boolean flag rather than a standard in and of itself.
> 
> Zack / Stan, do you agree with this approach?

Yes indeed.  We are starting to get some "but I want to use C99
features with ObjC" requests, and the simplest way to deal with
it is to have ObjC as a semi-self-contained set of extensions
to random C dialects.

Amusingly, some of Zem's ObjC++ support bits bear an uncanny
resemblance to parts of your patch...

> This patch does that, and removes -lang-objc++ (internal to cpplib,
> and unused by the driver since we don't do objc++ yet, so should not be
> an issue).  When we do obj-c++, the driver would either pass -lang-objc
> and the default c++ standard to the common front-end, or if the front
> ends are still separate, the cc1objplus would default things correctly
> like cc1obj does now.

We've got some patches that will go part of the way to eliminating
the need for a separate cc1obj, should be submitting those soon.

> I also removed the -+ option, whose semantics were incredibly vague,
> and have therefore changed with time.  The option was undocumented apart
> from in --help, not passed on by the driver, and unused to the best of
> my knowledge.
> 
> OK with you Zack and Stan?

OK with me.

Stan