2011-07-28 1 views
4

Lorsque j'essaie de créer ma cible de test sur mon iPad1 (4.3.5) ou iPhone4 (4.3.5), l'erreur suivante est générée par Xcode 4 (Build 4A304a):Obtention d'une erreur LLVM lors de la création d'un périphérique, mais pas dans le simulateur

Internal compiler error: tree check: expected tree that contains 'decl with visibility' structure, have 'const_decl' in c_common_truthvalue_conversion 

Mais pas quand est activé le test cible pour construire dans le simulateur.

La ligne de code qui est Borking est

GHAssertNotNULL(xxxObject, @"xxxObject could not be created"); 

(objets ont été renommés pour protéger les innocents ;-)) Mais je peux dire qu'il est un singleton.

J'ai cherché google et n'a pas obtenu quelque chose de pertinent pour cette erreur. Merci à l'avance Ian.

+0

Avant que quelqu'un ne le suggère j'ai déjà réalisé le produit -> propre. – ShogoDodo

+0

Comme je ne peux pas répondre à ma propre question pour encore 6 heures, voici la réponse que j'ai tenté de soumettre: - – ShogoDodo

+0

Je pense avoir répondu au problème. Au départ, c'était une erreur d'écolier en mon nom. Je n'aurais pas dû tester null lorsque la condition d'erreur renvoyée serait nulle. Sons facile-peasy jusqu'ici. J'ai corrigé le code et compilé à nouveau. Même erreur mais un scénario très différent, effectuant un plus grand que la comparaison entre une valeur off_t et zéro (cast à off_t). Pour couper court à une histoire courte, je soupçonne que le problème est lié à 32 v 64 bits (respectivement entre l'iPad et le simulateur). – ShogoDodo

Répondre

2

J'ai vécu la même erreur du compilateur:

internal compiler error: tree check: expected tree that contains 'decl with visibility' structure, have 'const_decl' in c_common_truthvalue_conversion, at c-common.c:2836 

En utilisant Xcode 4.1 avec GHUnitIOS-0.4.32 (et GHUnitIOS-0.4.31) lors de la construction pour les appareils iOS. Notez qu'il n'y a pas de problème lors de la construction du simulateur.

Les erreurs de complément impliquent des appels à GHAssertNotEqualObjects et GHAssertNotEquals.

Le modèle de code que j'utilisais quand j'ai reçu l'erreur du compilateur a des éléments suivants:

- (void) test_isEqual { 
    SomeObject *foo = [[SomeObject alloc] initWithValue: 1]; 
    SomeObject *bar = [[SomeObject alloc] initWithValue: 2]; 

    GHAssertNotEquals(bar, foo, @"Different Objects, different values - different pointers"); 
    GHAssertNotEqualObjects(bar, foo, @"Different Objects, different values - different pointers (calls isEqual)"); 
} 

j'ai pu compiler le code avec la modification suivante:

- (void) test_isEqual { 
    NSString *comment; 
    SomeObject *foo = [[SomeObject alloc] initWithValue: 1]; 
    SomeObject *bar = [[SomeObject alloc] initWithValue: 2]; 

    comment = @"Different Objects, different values - different pointers"; 
    GHAssertNotEquals(bar, foo, comment); 

    comment = @"Different Objects, different values - different pointers (calls isEqual)"; 
    GHAssertNotEqualObjects(bar, foo, comment); 
} 

Notez que appelle GHAssertEqualObjects, , GHAssertFalse, GHAssertNil, GHAssertNotNil et GHAssertTrue en utilisant un const NSString, c'est-à-dire @ "une chaîne", a fait pas provoquer une erreur de compilation.

En regardant dans #define GHAssertNotEquals(a1, a2, description, ...) et #define GHAssertEqualObjects(a1, a2, description, ...) et leur utilisation de description, les deux appellent GHComposeString(description, ##__VA_ARGS__), tout comme les autres macros qui fonctionnent.

+0

Thx! J'ai eu le même problème. J'ai été capable de contourner le problème en utilisant une macro d'assertion personnalisée légèrement différente. En passant le pointeur de la constante chaîne, plutôt que de l'indiquer dans l'appel de la fonction, j'ai surmonté le problème de manière fiable. – pchap10k

Questions connexes