From 6ea25fe9ceaa540a96046e2719b7ee20ab83e5e8 Mon Sep 17 00:00:00 2001 From: Jordan Rose Date: Tue, 10 Jul 2012 00:20:57 +0000 Subject: [PATCH] Add an explanation of -Wobjc-literal-compare to the "Objective-C Literals" page (per Jean-Daniel's suggestion to keep around an explanation of why direct comparisons on ObjC literals are a bad idea) llvm-svn: 159972 --- clang/docs/ObjectiveCLiterals.html | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/clang/docs/ObjectiveCLiterals.html b/clang/docs/ObjectiveCLiterals.html index 33f73e4a5b91..11751a6acda8 100644 --- a/clang/docs/ObjectiveCLiterals.html +++ b/clang/docs/ObjectiveCLiterals.html @@ -328,6 +328,12 @@ object[key] = newValue;

Programs can use object subscripting with Objective-C object pointers of type id. Normal dynamic message send rules apply; the compiler must see some declaration of the subscripting methods, and will pick the declaration seen first.

+

Caveats

+ +

Objects created using the literal or boxed expression syntax are not guaranteed to be uniqued by the runtime, but nor are they guaranteed to be newly-allocated. As such, the result of performing direct comparisons against the location of an object literal (using ==, !=, <, <=, >, or >=) is not well-defined. This is usually a simple mistake in code that intended to call the isEqual: method (or the compare: method).

+ +

This caveat applies to compile-time string literals as well. Historically, string literals (using the @"..." syntax) have been uniqued across translation units during linking. This is an implementation detail of the compiler and should not be relied upon. If you are using such code, please use global string constants instead (NSString * const MyConst = @"...") or use isEqual:.

+

Grammar Additions

To support the new syntax described above, the Objective-C @-expression grammar has the following new productions: