I get a lot of failures in obj(c|-c++) with yosemite (4.9.2 and 5.0, see https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg02799.html). AFAICT they are of the kind FAIL: objc.dg/headers.m -fnext-runtime (test for excess errors) Excess errors: /usr/include/objc/NSObject.h:22:4: error: unknown type name 'instancetype' /usr/include/objc/NSObject.h:36:4: error: unknown type name 'instancetype' /usr/include/objc/NSObject.h:38:4: error: unknown type name 'instancetype' /usr/include/objc/NSObject.h:60:4: error: unknown type name 'instancetype' /usr/include/objc/NSObject.h:62:4: error: unknown type name 'instancetype' /usr/include/objc/NSObject.h:63:4: error: unknown type name 'instancetype' /usr/include/objc/NSObject.h:64:4: error: unknown type name 'instancetype' /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:187:110: error: expected ')' before '^' token /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:187:112: error: expected ')' before '(' token /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:188:41: error: expected ')' before '^' token /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:188:43: error: expected ')' before '(' token
Some NSObject methods that used to return (id) now return (instancetype). Only NSObject has this, and the list includes: self, retain, autorelease, init, new, alloc* The "What's new in OS X Yosemite" document at https://developer.apple.com/Library/mac/releasenotes/MacOSX/WhatsNewInOSX/WhatsNewInOSX.pdf says: "Many frameworks on OS X have adopted small interface changes that take advantage of modern Objective-C syntax: […] Initialization methods are updated to have a return value of instancetype instead of id." It is documented further in Apple docs, or in clang here: http://clang.llvm.org/docs/LanguageExtensions.html I suppose as a first approach, we could make it equivalent to id.
(In reply to Francois-Xavier Coudert from comment #1) > I suppose as a first approach, we could make it equivalent to id. Not really, apparently: the answer there gives a quite complete description (and quotes the official Apple docs): http://stackoverflow.com/a/14652187
(In reply to Francois-Xavier Coudert from comment #2) > > I suppose as a first approach, we could make it equivalent to id. > > Not really, apparently: the answer there gives a quite complete description > (and quotes the official Apple docs): http://stackoverflow.com/a/14652187 Does it means that 'id' should be replaced with 'instancetype' in failing tests? What about the gnu-runtime?
(In reply to Dominique d'Humieres from comment #3) > Does it means that 'id' should be replaced with 'instancetype' in failing > tests? What about the gnu-runtime? No, we need to make the compiler understand 'instancetype'.
(In reply to Francois-Xavier Coudert from comment #4) > (In reply to Dominique d'Humieres from comment #3) > > Does it means that 'id' should be replaced with 'instancetype' in failing > > tests? What about the gnu-runtime? > > No, we need to make the compiler understand 'instancetype'. sadly, we spend almost all our darwin (volunteer) time chasing fall-out from other patches and very little remains for working on new features :-( I'd love to modernise the ObjC stuff - bearing in mind that the biggest killer there is that we don't support blocks in GCC (ObjC is essentially not much usable on darwin >= 11, without that). on the TODO ..
(In reply to Iain Sandoe from comment #5) > (In reply to Francois-Xavier Coudert from comment #4) > > (In reply to Dominique d'Humieres from comment #3) > > > Does it means that 'id' should be replaced with 'instancetype' in failing > > > tests? What about the gnu-runtime? > > > > No, we need to make the compiler understand 'instancetype'. > > sadly, we spend almost all our darwin (volunteer) time chasing fall-out from > other patches and very little remains for working on new features :-( > > I'd love to modernise the ObjC stuff - bearing in mind that the biggest > killer there is that we don't support blocks in GCC (ObjC is essentially not > much usable on darwin >= 11, without that). > > on the TODO .. Perhaps Iain can chime in on this. My recollection is that, while all of the changes out of the Apple gcc branch from prior to the GPLv3 rupture were merged in a few years ago, only limited attempts were made towards syncing with further upstream changes. I think those mainly involved adapting to breakage from system header changes. IMHO, it s pretty much a lost cause unless resources are committed to attempt to match the feature set of the current objective c in clang/llvm. I don't even know if Apple still attempts to distinguish the objective c changes. I think it went from Objective C 2.0 to Modern Objective C, no? Interestingly, if you scan the /usr/include/objc headers in Yosemite for copyright changes only NSObjCRuntime.h and NSObject.h have 2012 copyrights with the rest at 2007 or earlier. FYI, I believe this lists the changes in Modern Objective C... https://developer.apple.com/library/ios/releasenotes/ObjectiveC/ModernizationObjC/AdoptingModernObjective-C/AdoptingModernObjective-C.html
(In reply to Iain Sandoe from comment #5) > (In reply to Francois-Xavier Coudert from comment #4) > > (In reply to Dominique d'Humieres from comment #3) > > > Does it means that 'id' should be replaced with 'instancetype' in failing > > > tests? What about the gnu-runtime? > > > > No, we need to make the compiler understand 'instancetype'. > > sadly, we spend almost all our darwin (volunteer) time chasing fall-out from > other patches and very little remains for working on new features :-( > > I'd love to modernise the ObjC stuff - bearing in mind that the biggest > killer there is that we don't support blocks in GCC (ObjC is essentially not > much usable on darwin >= 11, without that). > > on the TODO .. If I remember correctly, the blocks issue is problematic because of the blocks runtime's license, so that whole package would have to be reverse engineered to be under GPLv3, no?
(In reply to howarth from comment #7) > > If I remember correctly, the blocks issue is problematic because of the > blocks runtime's license, so that whole package would have to be reverse > engineered to be under GPLv3, no? I just googled the text of the license for the blocks runtime (i.e. libclosure), and it looks like it's the MIT license... can't MIT-licensed packages be used in GPLed projects? After accounting for the ambiguity of the name, the GNU license list seems to say they're compatible: https://www.gnu.org/licenses/license-list.html#X11License or https://www.gnu.org/licenses/license-list.html#Expat The libclosure license can be found at the top of: http://opensource.apple.com/source/libclosure/libclosure-65/BlockImplementation.txt or http://opensource.apple.com/source/libclosure/libclosure-65/BlockSpec.rtf (if anyone wants to verify)
(In reply to Eric Gallager from comment #8) > (In reply to howarth from comment #7) > > > > If I remember correctly, the blocks issue is problematic because of the > > blocks runtime's license, so that whole package would have to be reverse > > engineered to be under GPLv3, no? > > I just googled the text of the license for the blocks runtime (i.e. > libclosure), and it looks like it's the MIT license... can't MIT-licensed > packages be used in GPLed projects? After accounting for the ambiguity of > the name, the GNU license list seems to say they're compatible: > > https://www.gnu.org/licenses/license-list.html#X11License > or > https://www.gnu.org/licenses/license-list.html#Expat > > The libclosure license can be found at the top of: > http://opensource.apple.com/source/libclosure/libclosure-65/ > BlockImplementation.txt > or > http://opensource.apple.com/source/libclosure/libclosure-65/BlockSpec.rtf > (if anyone wants to verify) The relevant files are those in compiler-rt/lib/BlocksRuntime. There are only three files and those all have an Apple license... * Copyright 2008-2010 Apple, Inc. Permission is hereby granted, free of charge, * to any person obtaining a copy of this software and associated documentation * files (the "Software"), to deal in the Software without restriction, * including without limitation the rights to use, copy, modify, merge, publish, * distribute, sublicense, and/or sell copies of the Software, and to permit * persons to whom the Software is furnished to do so, subject to the following * conditions: * * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE * SOFTWARE.
If I replace the files /usr/include/objc/NSObject.h and /System/Library/Frameworks/Foundation.framework/Headers/NSString.h with the corresponding files from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/ The errors reduce to === obj-c++ tests === Running target unix/-m32 FAIL: obj-c++.dg/cxx-ivars-3.mm -fnext-runtime execution test FAIL: obj-c++.dg/gnu-api-2-objc.mm -fnext-runtime execution test === obj-c++ Summary for unix/-m32 === # of expected passes 3151 # of unexpected failures 2 # of expected failures 2 # of unsupported tests 68 Running target unix/-m64 FAIL: obj-c++.dg/gnu-api-2-objc.mm -fnext-runtime execution test FAIL: obj-c++.dg/isa-field-1.mm -fnext-runtime (test for excess errors) FAIL: obj-c++.dg/try-catch-2.mm -fnext-runtime execution test FAIL: obj-c++.dg/try-catch-9.mm -fnext-runtime execution test === obj-c++ Summary for unix/-m64 === # of expected passes 3090 # of unexpected failures 4 # of expected failures 19 # of unsupported tests 74 === obj-c++ Summary === # of expected passes 6241 # of unexpected failures 6 # of expected failures 21 # of unsupported tests 142 /opt/gcc/p_build/gcc/testsuite/obj-c++/../../xg++ version 5.0.0 20141219 (experimental) [trunk revision 218883p2] (GCC) === objc tests === Running target unix/-m32 FAIL: objc.dg/call-super-2.m -fnext-runtime (test for warnings, line 104) FAIL: objc.dg/call-super-2.m -fnext-runtime (test for warnings, line 74) FAIL: objc.dg/gnu-api-2-objc.m -fnext-runtime execution test FAIL: objc.dg/ivar-scope-4.m -fnext-runtime execution test FAIL: objc.dg/objc-foreach-4.m -fnext-runtime (test for excess errors) UNRESOLVED: objc.dg/objc-foreach-4.m -fnext-runtime compilation failed to produce executable UNRESOLVED: objc.dg/objc-foreach-5.m -fnext-runtime scan-assembler _addStuffUp: FAIL: objc.dg/objc-foreach-5.m -fnext-runtime (test for excess errors) === objc Summary for unix/-m32 === # of expected passes 6124 # of unexpected failures 6 # of expected failures 6 # of unresolved testcases 2 # of unsupported tests 85 Running target unix/-m64 FAIL: objc.dg/call-super-2.m -fnext-runtime (test for warnings, line 104) FAIL: objc.dg/call-super-2.m -fnext-runtime (test for warnings, line 74) FAIL: objc.dg/exceptions-2.m -fnext-runtime execution test FAIL: objc.dg/gnu-api-2-objc.m -fnext-runtime execution test FAIL: objc.dg/isa-field-1.m -fnext-runtime (test for excess errors) FAIL: objc.dg/objc-foreach-4.m -fnext-runtime (test for excess errors) UNRESOLVED: objc.dg/objc-foreach-4.m -fnext-runtime compilation failed to produce executable UNRESOLVED: objc.dg/objc-foreach-5.m -fnext-runtime scan-assembler _addStuffUp: FAIL: objc.dg/objc-foreach-5.m -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/forward-1.m -O0 -fnext-runtime execution test FAIL: objc.dg/torture/forward-1.m -O1 -fnext-runtime execution test FAIL: objc.dg/torture/forward-1.m -O2 -fnext-runtime execution test FAIL: objc.dg/torture/forward-1.m -O2 -flto -fnext-runtime execution test FAIL: objc.dg/torture/forward-1.m -O2 -flto -flto-partition=none -fnext-runtime execution test FAIL: objc.dg/torture/forward-1.m -O3 -fomit-frame-pointer -fnext-runtime execution test FAIL: objc.dg/torture/forward-1.m -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -fnext-runtime execution test FAIL: objc.dg/torture/forward-1.m -O3 -fomit-frame-pointer -funroll-loops -fnext-runtime execution test FAIL: objc.dg/torture/forward-1.m -O3 -g -fnext-runtime execution test FAIL: objc.dg/torture/forward-1.m -Os -fnext-runtime execution test === objc Summary for unix/-m64 === # of expected passes 5957 # of unexpected failures 17 # of expected failures 6 # of unresolved testcases 2 # of unsupported tests 91 === objc Summary === # of expected passes 12081 # of unexpected failures 23 # of expected failures 12 # of unresolved testcases 4 # of unsupported tests 176 /opt/gcc/p_build/gcc/xgcc version 5.0.0 20141219 (experimental) [trunk revision 218883p2] (GCC) The new failures compared to darwin13 are FAIL: obj-c++.dg/isa-field-1.mm -fnext-runtime (test for excess errors) with -m64, FAIL: objc.dg/objc-foreach-4.m -fnext-runtime (test for excess errors) UNRESOLVED: objc.dg/objc-foreach-4.m -fnext-runtime compilation failed to produce executable UNRESOLVED: objc.dg/objc-foreach-5.m -fnext-runtime scan-assembler _addStuffUp: FAIL: objc.dg/objc-foreach-5.m -fnext-runtime (test for excess errors) with -m32, and FAIL: objc.dg/isa-field-1.m -fnext-runtime (test for excess errors) FAIL: objc.dg/objc-foreach-4.m -fnext-runtime (test for excess errors) UNRESOLVED: objc.dg/objc-foreach-4.m -fnext-runtime compilation failed to produce executable UNRESOLVED: objc.dg/objc-foreach-5.m -fnext-runtime scan-assembler _addStuffUp: FAIL: objc.dg/objc-foreach-5.m -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/forward-1.m -O0 -fnext-runtime execution test FAIL: objc.dg/torture/forward-1.m -O1 -fnext-runtime execution test FAIL: objc.dg/torture/forward-1.m -O2 -fnext-runtime execution test FAIL: objc.dg/torture/forward-1.m -O2 -flto -fnext-runtime execution test FAIL: objc.dg/torture/forward-1.m -O2 -flto -flto-partition=none -fnext-runtime execution test FAIL: objc.dg/torture/forward-1.m -O3 -fomit-frame-pointer -fnext-runtime execution test FAIL: objc.dg/torture/forward-1.m -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions -fnext-runtime execution test FAIL: objc.dg/torture/forward-1.m -O3 -fomit-frame-pointer -funroll-loops -fnext-runtime execution test FAIL: objc.dg/torture/forward-1.m -O3 -g -fnext-runtime execution test FAIL: objc.dg/torture/forward-1.m -Os -fnext-runtime execution test with -m64. The errors for are of the kind objc[1436]: -[Forwarder display]: unrecognized selector sent to instance 0x7f9ce9d04f30 (no message forward handler is installed) Is there a canonical way to force obj(c|-c++) to use the include files in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/ instead of the native files in /usr and /System? Note that some remaining errors will go away if the same is used for /System/Library/Frameworks/Foundation.framework/Headers/NSArray.h.
> Note that some remaining errors will go away if the same is used for > /System/Library/Frameworks/Foundation.framework/Headers/NSArray.h. This fixes the failures of objc.dg/objc-foreach-(4|5).m.
Regarding the last few comments: all this comes, AFAICT, from the front-end not recognizing "instancetype". I don't think we can get out of this by fixing headers or anything else: it's an extension to Objective C, and if Apple is going to use it widely, we need to support it in our front-end. I know it's not very helpful, because I cannot code the changes myself. I've tried to look at the front-end code to see where "id" is defined, but it's not very clear. In any case, what I wanted to say is: I don't think we need more analysis of this. We need someone who can do the work :)
I agree, kludging around headers is not going to work - we need to find time to modernise the ObjC implementation. it's on the TODO… Supporting ObjC on Darwin is quite important - and we're well behind, but I doubt anyone other than me (as things stand) is actually going to step up to do the work.
Created attachment 34310 [details] Arrange for the instancetype type to be recognised This makes "instancetype" a synonym for "id". So, in round terms it should work as expected - however: (a) there's nothing to prevent the User from using it in the Wrong Place (i.e. somewhere other than a return type). (b) there's none of the additional analysis that instancetype allows to provide greater type security. So it's part #1 of N that will be needed to implement this part of the modernisation. ==== NOTE that on my tests we still fail to parse the system headers owing to the use of blocks (but that's a different, and bigger, problem).
With the patch in comment 14, I get === obj-c++ Summary for unix/-m64 === # of expected passes 3073 # of unexpected failures 13 # of expected failures 19 # of unresolved testcases 8 # of unsupported tests 74 === obj-c++ Summary === # of expected passes 6207 # of unexpected failures 24 # of expected failures 21 # of unresolved testcases 16 # of unsupported tests 142 and === objc Summary for unix/-m64 === # of expected passes 5939 # of unexpected failures 27 # of expected failures 6 # of unresolved testcases 10 # of unsupported tests 91 === objc Summary === # of expected passes 12045 # of unexpected failures 43 # of expected failures 12 # of unresolved testcases 20 # of unsupported tests 176 The additional failures compared to the use of the 10.9 SDK are FAIL: obj-c++.dg/torture/strings/const-cfstring-1.mm -O* -fnext-runtime (test for excess errors) FAIL: objc.dg/torture/strings/const-cfstring-1.m -O* -fnext-runtime (test for excess errors) FAIL: objc.dg/objc-foreach-4.m -fnext-runtime (test for excess errors) FAIL: objc.dg/objc-foreach-5.m -fnext-runtime (test for excess errors) Apparently they are related to the fact that NS_BLOCKS_AVAILABLE is no longer checked.
We can fixincludes NS_BLOCKS_AVAILABLE support back in, this would disappear interfaces that cannot be supported. In the past, this was a safe thing to do, and might well be still safe wrt the runtime. Deeper language issues would likely need someone to do real work. No really nice fix for that other than someone who wanted to do the work stepping forward. Until then, SDK support for older OSes might be the old way to get code compiled on newer systems. We should be able to steal code from MIT style runtimes to put into newer systems, if we can get FSF approval for incorporating code they don't own. This should be easy enough, we don't vend sell or ship a competing abi compatible runtime, so, bundling one I think should be trivial, if we want to.
(In reply to mrs@gcc.gnu.org from comment #16) > We can fixincludes NS_BLOCKS_AVAILABLE support back in, this would disappear > interfaces that cannot be supported. In the past, this was a safe thing to > do, and might well be still safe wrt the runtime. > > Deeper language issues would likely need someone to do real work. No really > nice fix for that other than someone who wanted to do the work stepping > forward. Until then, SDK support for older OSes might be the old way to get > code compiled on newer systems. > > We should be able to steal code from MIT style runtimes to put into newer > systems, if we can get FSF approval for incorporating code they don't own. > This should be easy enough, we don't vend sell or ship a competing abi > compatible runtime, so, bundling one I think should be trivial, if we want > to. two things here: (1) making FSF ObjC useful again on Darwin - the only solution there realistically is to implement blocks [TBH, this applies outside of ObjC too]. Likely there are two candidates for that job - mrs and ids .. ;) .. if there were some way to split the task up.. I believe this is rapidly becoming a show-stopper for FSF GCC on darwin. :( (2) Having a non-fragile ObjC library on Linux (and/or other interested *nix hosts). My understanding is that David Chisnall's libobjc2 might fit the bill for this (BSD license) ..
For the record with darwin15 I had to add /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSEnumerator.h /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSObject.h /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSValue.h from the 10.9 SDK to /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSArray.h /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSString.h /usr/include/objc/NSObject.h
Bug 78352 is related
(In reply to Dominique d'Humieres from comment #18) > For the record with darwin15 I had to add > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/ > NSEnumerator.h > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSObject.h > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSValue.h > > from the 10.9 SDK to > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSArray.h > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSString.h > /usr/include/objc/NSObject.h that seems dangerous
(In reply to Eric Gallager from comment #20) > (In reply to Dominique d'Humieres from comment #18) > > For the record with darwin15 I had to add > > > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/ > > NSEnumerator.h > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSObject.h > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSValue.h > > > > from the 10.9 SDK to > > > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSArray.h > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSString.h > > /usr/include/objc/NSObject.h > > that seems dangerous Not so dangerous as it seems. Many (most, in fact) of the failures seen from GCC Objective-C are caused by missing support for new features that have been introduced into the vendor's headers. Short list: Apple Blocks, Lightweight Generics, Nullability, Syntactic sugar on ID. I'm working on a set of replacement test-suite headers that allow us to test the things that _do_ work on GCC Objective-C, and expose any real regressions. Tests on Darwin13 and earlier show that we are not in such bad shape as the header fails make it appear. I hope to get these test fixes (there's a set of three PRs related to excess fails on Yosemite+) in place soon - and to back port them to the open branches.
(In reply to Iain Sandoe from comment #21) > (In reply to Eric Gallager from comment #20) > > (In reply to Dominique d'Humieres from comment #18) > > > For the record with darwin15 I had to add > > > > > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/ > > > NSEnumerator.h > > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSObject.h > > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSValue.h > > > > > > from the 10.9 SDK to > > > > > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSArray.h > > > /System/Library/Frameworks/Foundation.framework/Versions/C/Headers/NSString.h > > > /usr/include/objc/NSObject.h > > > > that seems dangerous > > Not so dangerous as it seems. > > Many (most, in fact) of the failures seen from GCC Objective-C are caused by > missing support for new features that have been introduced into the vendor's > headers. Short list: Apple Blocks, Lightweight Generics, Nullability, > Syntactic sugar on ID. Blocks support at least is bug 78352; are there bugs open for the other 3? > I'm working on a set of replacement test-suite headers that allow us to > test the things that _do_ work on GCC Objective-C, and expose any real > regressions. > > Tests on Darwin13 and earlier show that we are not in such bad shape as the > header fails make it appear. > > I hope to get these test fixes (there's a set of three PRs related to excess > fails on Yosemite+) in place soon - and to back port them to the open > branches.
track the progress to solving this with the meta-bug. *** This bug has been marked as a duplicate of bug 90709 ***