[cfe-dev] implemented a new switch, having trouble testing

[John McCall]

On Mar 27, 2012, at 5:51 PM, Daniel DeCovnick wrote:
> There's been a lot of discussion lately on the Apple objc-language list about how it'd be nice if there was a compiler switch to specify what class should be used for numeric, array, and dictionary literals, similar to -fconstant-string-class. So I went ahead and implemented -fobjc-numeric-literal-class (with -fobjc-array-literal-class and -fobjc-dictionary-literal-class to come)
> 
> The diff: http://pastie.org/3663039
> 
> Or at least I think I did. I'm not sure, because I haven't been able to test it properly. I tried to write a test case in SemaObjC based on the objc-literal-nsnumber test: 
> 
> http://pastie.org/3663058
> 
> but the test always fails, with this error: 
> "error: 'error' diagnostics seen but not expected: 
>  (frontend): unknown argument: '-fobjc-numeric-literal-class=MYNumber'" 

The -cc1 option you added takes its argument separately, i.e.
  -fobjc-numeric-literal-class MYNumber
And indeed this is exactly the pattern that you've taught the driver to emit.  You just need to change your test, which is using -cc1 options, to use this separated form instead of the = form.

Sending patches to this list (or cfe-commits) is a fine way to get them applied.  Of course, they do have to go through code and design review.  So let's get started. :)

The first thing is that, while you're writing up tests for all this, please also add driver tests to ensure that it propagates your argument correctly.

With that out of the way, I have a pair of design concerns.

The first is that I find it likely that people will generally want these options in a "package":  i.e. they will want to simultaneously specify a string class, a number class, an array class, a dictionary class, and classes for whatever other literals we end up adding, plus any other sort of customization they desire.  At some point, specifying this stuff individually doesn't seem like the right abstraction anymore.  We do not want to encourage a model where individual files in a project use different types for their literals — that just seems like it'd be a bizarre experience for the programmer.

The second is that I'm concerned that there may be other knobs that people want to turn, and moreover that the set of these knobs is only likely to increase.  For example:
  - the selectors used for the new literals
  - the supported index types for subscripting and their mappings to selectors
  - the order of arguments to methods which take multiple arguments
  - the layout of constant strings
  - whether to permit constant emission of non-string literals, if that's ever added
  - the layout of such constant literals, if added and permitted by the library
  - whether to permit optimized emission of non-constant literals, if that's ever added (e.g. using a call into the runtime with non-standard ownership transfer rules under ARC)
etc.

Basically, before we blithely add three more command-line switches, I want to know that this isn't going to turn into twenty command-line switches that are still ultimately inadequate for the needs of the authors of replacement libraries.

I'm willing to entertain the idea of abstracting over the ObjC library the same way we abstract over the ObjC runtime, which would give people a lot more flexibility, at the cost of requiring them to write some compiler code (private libraries would want to load this code with a plugin).

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120327/25581f5e/attachment.html>