[LLVMbugs] [Bug 17613] New: No way to override hard-coded Objective-C identifiers (class name or selectors)

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Fri Oct 18 04:09:39 PDT 2013


http://llvm.org/bugs/show_bug.cgi?id=17613

            Bug ID: 17613
           Summary: No way to override hard-coded Objective-C identifiers
                    (class name or selectors)
           Product: clang
           Version: 3.3
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
          Assignee: unassignedclangbugs at nondot.org
          Reporter: drawtree at me.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Clang has several hard-coded identifiers for Objective-C.
I think at least these identifiers are hard-coded and cannot be overridden. (or
at least the overriding method is not well known)

- Classes for literal. (`NSNumber`, `NSString`, `NSArray`, `NSDictionary`)
- Selectors to create literal. (such as `numberWithInt:` ??? I have no idea for
strings)
- Selectors to access some syntax. (such as `objectForKeyedSubscript:`)
- Protocol and selector for for..in loop. (`NSFastEnumeration`)

Some of them can be overridden using `@compatibility_alias` keyword, but it's
just workaround, not a ultimate solution.

Currently, AFAIK, the only way to override this is modifying compiler source
code. 
And this discourages writing completely new framework/library from scratch by
forcing some source-level compatibility to Apple's Foundation framework.

It would be great if these identifiers can be overridden at compile time via
command-line parameters or configuration files.

I don't know how `libclang` handles this, but if `libclang` can override these
identifiers, I think that would be awesome.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20131018/ad2b6452/attachment.html>


More information about the llvm-bugs mailing list