1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" 2 "http://www.w3.org/TR/html4/strict.dtd"> 3 <!-- Material used from: HTML 4.01 specs: http://www.w3.org/TR/html401/ --> 4 <html> 5 <head> 6 <META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> 7 <title>Clang Language Extensions</title> 8 <link type="text/css" rel="stylesheet" href="../menu.css"> 9 <link type="text/css" rel="stylesheet" href="../content.css"> 10 <style type="text/css"> 11 td { 12 vertical-align: top; 13 } 14 th { background-color: #ffddaa; } 15 </style> 16 </head> 17 <body> 18 19 <!--#include virtual="../menu.html.incl"--> 20 21 <div id="content"> 22 23 <h1>Clang Language Extensions</h1> 24 25 <ul> 26 <li><a href="#intro">Introduction</a></li> 27 <li><a href="#feature_check">Feature Checking Macros</a></li> 28 <li><a href="#has_include">Include File Checking Macros</a></li> 29 <li><a href="#builtinmacros">Builtin Macros</a></li> 30 <li><a href="#vectors">Vectors and Extended Vectors</a></li> 31 <li><a href="#deprecated">Messages on <tt>deprecated</tt> and <tt>unavailable</tt> attributes</a></li> 32 <li><a href="#attributes-on-enumerators">Attributes on enumerators</a></li> 33 <li><a href="#user_specified_system_framework">'User-Specified' System Frameworks</a></li> 34 <li><a href="#availability">Availability attribute</a></li> 35 <li><a href="#checking_language_features">Checks for Standard Language Features</a> 36 <ul> 37 <li><a href="#cxx98">C++98</a> 38 <ul> 39 <li><a href="#cxx_exceptions">C++ exceptions</a></li> 40 <li><a href="#cxx_rtti">C++ RTTI</a></li> 41 </ul></li> 42 <li><a href="#cxx11">C++11</a> 43 <ul> 44 <li><a href="#cxx_access_control_sfinae">C++11 SFINAE includes access control</a></li> 45 <li><a href="#cxx_alias_templates">C++11 alias templates</a></li> 46 <li><a href="#cxx_alignas">C++11 alignment specifiers</a></li> 47 <li><a href="#cxx_attributes">C++11 attributes</a></li> 48 <li><a href="#cxx_constexpr">C++11 generalized constant expressions</a></li> 49 <li><a href="#cxx_decltype">C++11 <tt>decltype()</tt></a></li> 50 <li><a href="#cxx_default_function_template_args">C++11 default template arguments in function templates</a></li> 51 <li><a href="#cxx_defaulted_functions">C++11 defaulted functions</a></li> 52 <li><a href="#cxx_delegating_constructor">C++11 delegating constructors</a></li> 53 <li><a href="#cxx_deleted_functions">C++11 deleted functions</a></li> 54 <li><a href="#cxx_explicit_conversions">C++11 explicit conversion functions</a></li> 55 <li><a href="#cxx_generalized_initializers">C++11 generalized initializers</a></li> 56 <li><a href="#cxx_implicit_moves">C++11 implicit move constructors/assignment operators</a></li> 57 <li><a href="#cxx_inheriting_constructors">C++11 inheriting constructors</a></li> 58 <li><a href="#cxx_inline_namespaces">C++11 inline namespaces</a></li> 59 <li><a href="#cxx_lambdas">C++11 lambdas</a></li> 60 <li><a href="#cxx_local_type_template_args">C++11 local and unnamed types as template arguments</a></li> 61 <li><a href="#cxx_noexcept">C++11 noexcept specification</a></li> 62 <li><a href="#cxx_nonstatic_member_init">C++11 in-class non-static data member initialization</a></li> 63 <li><a href="#cxx_nullptr">C++11 nullptr</a></li> 64 <li><a href="#cxx_override_control">C++11 override control</a></li> 65 <li><a href="#cxx_range_for">C++11 range-based for loop</a></li> 66 <li><a href="#cxx_raw_string_literals">C++11 raw string literals</a></li> 67 <li><a href="#cxx_rvalue_references">C++11 rvalue references</a></li> 68 <li><a href="#cxx_reference_qualified_functions">C++11 reference-qualified functions</a></li> 69 <li><a href="#cxx_static_assert">C++11 <tt>static_assert()</tt></a></li> 70 <li><a href="#cxx_auto_type">C++11 type inference</a></li> 71 <li><a href="#cxx_strong_enums">C++11 strongly-typed enumerations</a></li> 72 <li><a href="#cxx_trailing_return">C++11 trailing return type</a></li> 73 <li><a href="#cxx_unicode_literals">C++11 Unicode string literals</a></li> 74 <li><a href="#cxx_unrestricted_unions">C++11 unrestricted unions</a></li> 75 <li><a href="#cxx_user_literals">C++11 user-defined literals</a></li> 76 <li><a href="#cxx_variadic_templates">C++11 variadic templates</a></li> 77 </ul></li> 78 <li><a href="#c11">C11</a> 79 <ul> 80 <li><a href="#c_alignas">C11 alignment specifiers</a></li> 81 <li><a href="#c_atomic">C11 atomic operations</a></li> 82 <li><a href="#c_generic_selections">C11 generic selections</a></li> 83 <li><a href="#c_static_assert">C11 <tt>_Static_assert()</tt></a></li> 84 </ul></li> 85 </ul></li> 86 <li><a href="#checking_type_traits">Checks for Type Traits</a></li> 87 <li><a href="#blocks">Blocks</a></li> 88 <li><a href="#objc_features">Objective-C Features</a> 89 <ul> 90 <li><a href="#objc_instancetype">Related result types</a></li> 91 <li><a href="#objc_arc">Automatic reference counting</a></li> 92 <li><a href="#objc_fixed_enum">Enumerations with a fixed underlying type</a></li> 93 <li><a href="#objc_lambdas">Interoperability with C++11 lambdas</a></li> 94 <li><a href="#objc_object_literals_subscripting">Object Literals and Subscripting</a></li> 95 </ul> 96 </li> 97 <li><a href="#overloading-in-c">Function Overloading in C</a></li> 98 <li><a href="#complex-list-init">Initializer lists for complex numbers in C</a></li> 99 <li><a href="#builtins">Builtin Functions</a> 100 <ul> 101 <li><a href="#__builtin_shufflevector">__builtin_shufflevector</a></li> 102 <li><a href="#__builtin_unreachable">__builtin_unreachable</a></li> 103 <li><a href="#__sync_swap">__sync_swap</a></li> 104 </ul> 105 </li> 106 <li><a href="#targetspecific">Target-Specific Extensions</a> 107 <ul> 108 <li><a href="#x86-specific">X86/X86-64 Language Extensions</a></li> 109 </ul> 110 </li> 111 <li><a href="#analyzerspecific">Static Analysis-Specific Extensions</a></li> 112 <li><a href="#dynamicanalyzerspecific">Dynamic Analysis-Specific Extensions</a> 113 <ul> 114 <li><a href="#address_sanitizer">AddressSanitizer</a></li> 115 </ul> 116 </li> 117 <li><a href="#threadsafety">Thread Safety Annotation Checking</a> 118 <ul> 119 <li><a href="#ts_noanal"><tt>no_thread_safety_analysis</tt></a></li> 120 <li><a href="#ts_lockable"><tt>lockable</tt></a></li> 121 <li><a href="#ts_scopedlockable"><tt>scoped_lockable</tt></a></li> 122 <li><a href="#ts_guardedvar"><tt>guarded_var</tt></a></li> 123 <li><a href="#ts_ptguardedvar"><tt>pt_guarded_var</tt></a></li> 124 <li><a href="#ts_guardedby"><tt>guarded_by(l)</tt></a></li> 125 <li><a href="#ts_ptguardedby"><tt>pt_guarded_by(l)</tt></a></li> 126 <li><a href="#ts_acquiredbefore"><tt>acquired_before(...)</tt></a></li> 127 <li><a href="#ts_acquiredafter"><tt>acquired_after(...)</tt></a></li> 128 <li><a href="#ts_elf"><tt>exclusive_lock_function(...)</tt></a></li> 129 <li><a href="#ts_slf"><tt>shared_lock_function(...)</tt></a></li> 130 <li><a href="#ts_etf"><tt>exclusive_trylock_function(...)</tt></a></li> 131 <li><a href="#ts_stf"><tt>shared_trylock_function(...)</tt></a></li> 132 <li><a href="#ts_uf"><tt>unlock_function(...)</tt></a></li> 133 <li><a href="#ts_lr"><tt>lock_returned(l)</tt></a></li> 134 <li><a href="#ts_le"><tt>locks_excluded(...)</tt></a></li> 135 <li><a href="#ts_elr"><tt>exclusive_locks_required(...)</tt></a></li> 136 <li><a href="#ts_slr"><tt>shared_locks_required(...)</tt></a></li> 137 </ul> 138 </li> 139 </ul> 140 141 <!-- ======================================================================= --> 142 <h2 id="intro">Introduction</h2> 143 <!-- ======================================================================= --> 144 145 <p>This document describes the language extensions provided by Clang. In 146 addition to the language extensions listed here, Clang aims to support a broad 147 range of GCC extensions. Please see the <a 148 href="http://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html">GCC manual</a> for 149 more information on these extensions.</p> 150 151 <!-- ======================================================================= --> 152 <h2 id="feature_check">Feature Checking Macros</h2> 153 <!-- ======================================================================= --> 154 155 <p>Language extensions can be very useful, but only if you know you can depend 156 on them. In order to allow fine-grain features checks, we support three builtin 157 function-like macros. This allows you to directly test for a feature in your 158 code without having to resort to something like autoconf or fragile "compiler 159 version checks".</p> 160 161 <!-- ======================================================================= --> 162 <h3><a name="__has_builtin">__has_builtin</a></h3> 163 <!-- ======================================================================= --> 164 165 <p>This function-like macro takes a single identifier argument that is the name 166 of a builtin function. It evaluates to 1 if the builtin is supported or 0 if 167 not. It can be used like this:</p> 168 169 <blockquote> 170 <pre> 171 #ifndef __has_builtin // Optional of course. 172 #define __has_builtin(x) 0 // Compatibility with non-clang compilers. 173 #endif 174 175 ... 176 #if __has_builtin(__builtin_trap) 177 __builtin_trap(); 178 #else 179 abort(); 180 #endif 181 ... 182 </pre> 183 </blockquote> 184 185 186 <!-- ======================================================================= --> 187 <h3><a name="__has_feature_extension"> __has_feature and __has_extension</a></h3> 188 <!-- ======================================================================= --> 189 190 <p>These function-like macros take a single identifier argument that is the 191 name of a feature. <code>__has_feature</code> evaluates to 1 if the feature 192 is both supported by Clang and standardized in the current language standard 193 or 0 if not (but see <a href="#has_feature_back_compat">below</a>), while 194 <code>__has_extension</code> evaluates to 1 if the feature is supported by 195 Clang in the current language (either as a language extension or a standard 196 language feature) or 0 if not. They can be used like this:</p> 197 198 <blockquote> 199 <pre> 200 #ifndef __has_feature // Optional of course. 201 #define __has_feature(x) 0 // Compatibility with non-clang compilers. 202 #endif 203 #ifndef __has_extension 204 #define __has_extension __has_feature // Compatibility with pre-3.0 compilers. 205 #endif 206 207 ... 208 #if __has_feature(cxx_rvalue_references) 209 // This code will only be compiled with the -std=c++11 and -std=gnu++11 210 // options, because rvalue references are only standardized in C++11. 211 #endif 212 213 #if __has_extension(cxx_rvalue_references) 214 // This code will be compiled with the -std=c++11, -std=gnu++11, -std=c++98 215 // and -std=gnu++98 options, because rvalue references are supported as a 216 // language extension in C++98. 217 #endif 218 </pre> 219 </blockquote> 220 221 <p id="has_feature_back_compat">For backwards compatibility reasons, 222 <code>__has_feature</code> can also be used to test for support for 223 non-standardized features, i.e. features not prefixed <code>c_</code>, 224 <code>cxx_</code> or <code>objc_</code>.</p> 225 226 <p id="has_feature_for_non_language_features"> 227 Another use of <code>__has_feature</code> is to check for compiler features 228 not related to the language standard, such as e.g. 229 <a href="AddressSanitizer.html">AddressSanitizer</a>. 230 231 <p>If the <code>-pedantic-errors</code> option is given, 232 <code>__has_extension</code> is equivalent to <code>__has_feature</code>.</p> 233 234 <p>The feature tag is described along with the language feature below.</p> 235 236 <p>The feature name or extension name can also be specified with a preceding and 237 following <code>__</code> (double underscore) to avoid interference from a macro 238 with the same name. For instance, <code>__cxx_rvalue_references__</code> can be 239 used instead of <code>cxx_rvalue_references</code>.</p> 240 241 <!-- ======================================================================= --> 242 <h3><a name="__has_attribute">__has_attribute</a></h3> 243 <!-- ======================================================================= --> 244 245 <p>This function-like macro takes a single identifier argument that is the name 246 of an attribute. It evaluates to 1 if the attribute is supported or 0 if not. It 247 can be used like this:</p> 248 249 <blockquote> 250 <pre> 251 #ifndef __has_attribute // Optional of course. 252 #define __has_attribute(x) 0 // Compatibility with non-clang compilers. 253 #endif 254 255 ... 256 #if __has_attribute(always_inline) 257 #define ALWAYS_INLINE __attribute__((always_inline)) 258 #else 259 #define ALWAYS_INLINE 260 #endif 261 ... 262 </pre> 263 </blockquote> 264 265 <p>The attribute name can also be specified with a preceding and 266 following <code>__</code> (double underscore) to avoid interference from a macro 267 with the same name. For instance, <code>__always_inline__</code> can be used 268 instead of <code>always_inline</code>.</p> 269 270 <!-- ======================================================================= --> 271 <h2 id="has_include">Include File Checking Macros</h2> 272 <!-- ======================================================================= --> 273 274 <p>Not all developments systems have the same include files. 275 The <a href="#__has_include">__has_include</a> and 276 <a href="#__has_include_next">__has_include_next</a> macros allow you to 277 check for the existence of an include file before doing 278 a possibly failing #include directive.</p> 279 280 <!-- ======================================================================= --> 281 <h3><a name="__has_include">__has_include</a></h3> 282 <!-- ======================================================================= --> 283 284 <p>This function-like macro takes a single file name string argument that 285 is the name of an include file. It evaluates to 1 if the file can 286 be found using the include paths, or 0 otherwise:</p> 287 288 <blockquote> 289 <pre> 290 // Note the two possible file name string formats. 291 #if __has_include("myinclude.h") && __has_include(<stdint.h>) 292 # include "myinclude.h" 293 #endif 294 295 // To avoid problem with non-clang compilers not having this macro. 296 #if defined(__has_include) && __has_include("myinclude.h") 297 # include "myinclude.h" 298 #endif 299 </pre> 300 </blockquote> 301 302 <p>To test for this feature, use #if defined(__has_include).</p> 303 304 <!-- ======================================================================= --> 305 <h3><a name="__has_include_next">__has_include_next</a></h3> 306 <!-- ======================================================================= --> 307 308 <p>This function-like macro takes a single file name string argument that 309 is the name of an include file. It is like __has_include except that it 310 looks for the second instance of the given file found in the include 311 paths. It evaluates to 1 if the second instance of the file can 312 be found using the include paths, or 0 otherwise:</p> 313 314 <blockquote> 315 <pre> 316 // Note the two possible file name string formats. 317 #if __has_include_next("myinclude.h") && __has_include_next(<stdint.h>) 318 # include_next "myinclude.h" 319 #endif 320 321 // To avoid problem with non-clang compilers not having this macro. 322 #if defined(__has_include_next) && __has_include_next("myinclude.h") 323 # include_next "myinclude.h" 324 #endif 325 </pre> 326 </blockquote> 327 328 <p>Note that __has_include_next, like the GNU extension 329 #include_next directive, is intended for use in headers only, 330 and will issue a warning if used in the top-level compilation 331 file. A warning will also be issued if an absolute path 332 is used in the file argument.</p> 333 334 335 <!-- ======================================================================= --> 336 <h3><a name="__has_warning">__has_warning</a></h3> 337 <!-- ======================================================================= --> 338 339 <p>This function-like macro takes a string literal that represents a command 340 line option for a warning and returns true if that is a valid warning 341 option.</p> 342 343 <blockquote> 344 <pre> 345 #if __has_warning("-Wformat") 346 ... 347 #endif 348 </pre> 349 </blockquote> 350 351 <!-- ======================================================================= --> 352 <h2 id="builtinmacros">Builtin Macros</h2> 353 <!-- ======================================================================= --> 354 355 <dl> 356 <dt><code>__BASE_FILE__</code></dt> 357 <dd>Defined to a string that contains the name of the main input 358 file passed to Clang.</dd> 359 360 <dt><code>__COUNTER__</code></dt> 361 <dd>Defined to an integer value that starts at zero and is 362 incremented each time the <code>__COUNTER__</code> macro is 363 expanded.</dd> 364 365 <dt><code>__INCLUDE_LEVEL__</code></dt> 366 <dd>Defined to an integral value that is the include depth of the 367 file currently being translated. For the main file, this value is 368 zero.</dd> 369 370 <dt><code>__TIMESTAMP__</code></dt> 371 <dd>Defined to the date and time of the last modification of the 372 current source file.</dd> 373 374 <dt><code>__clang__</code></dt> 375 <dd>Defined when compiling with Clang</dd> 376 377 <dt><code>__clang_major__</code></dt> 378 <dd>Defined to the major marketing version number of Clang (e.g., the 379 2 in 2.0.1). Note that marketing version numbers should not be used to 380 check for language features, as different vendors use different numbering 381 schemes. Instead, use the <a href="#feature_check">feature checking 382 macros</a>.</dd> 383 384 <dt><code>__clang_minor__</code></dt> 385 <dd>Defined to the minor version number of Clang (e.g., the 0 in 386 2.0.1). Note that marketing version numbers should not be used to 387 check for language features, as different vendors use different numbering 388 schemes. Instead, use the <a href="#feature_check">feature checking 389 macros</a>.</dd> 390 391 <dt><code>__clang_patchlevel__</code></dt> 392 <dd>Defined to the marketing patch level of Clang (e.g., the 1 in 2.0.1).</dd> 393 394 <dt><code>__clang_version__</code></dt> 395 <dd>Defined to a string that captures the Clang marketing version, including 396 the Subversion tag or revision number, e.g., "1.5 (trunk 102332)".</dd> 397 </dl> 398 399 <!-- ======================================================================= --> 400 <h2 id="vectors">Vectors and Extended Vectors</h2> 401 <!-- ======================================================================= --> 402 403 <p>Supports the GCC, OpenCL, AltiVec and NEON vector extensions.</p> 404 405 <p>OpenCL vector types are created using <tt>ext_vector_type</tt> attribute. It 406 support for <tt>V.xyzw</tt> syntax and other tidbits as seen in OpenCL. An 407 example is:</p> 408 409 <blockquote> 410 <pre> 411 typedef float float4 <b>__attribute__((ext_vector_type(4)))</b>; 412 typedef float float2 <b>__attribute__((ext_vector_type(2)))</b>; 413 414 float4 foo(float2 a, float2 b) { 415 float4 c; 416 c.xz = a; 417 c.yw = b; 418 return c; 419 } 420 </pre> 421 </blockquote> 422 423 <p>Query for this feature with 424 <tt>__has_extension(attribute_ext_vector_type)</tt>.</p> 425 426 <p>Giving <tt>-faltivec</tt> option to clang enables support for AltiVec vector 427 syntax and functions. For example:</p> 428 429 <blockquote> 430 <pre> 431 vector float foo(vector int a) { 432 vector int b; 433 b = vec_add(a, a) + a; 434 return (vector float)b; 435 } 436 </pre> 437 </blockquote> 438 439 <p>NEON vector types are created using <tt>neon_vector_type</tt> and 440 <tt>neon_polyvector_type</tt> attributes. For example:</p> 441 442 <blockquote> 443 <pre> 444 typedef <b>__attribute__((neon_vector_type(8)))</b> int8_t int8x8_t; 445 typedef <b>__attribute__((neon_polyvector_type(16)))</b> poly8_t poly8x16_t; 446 447 int8x8_t foo(int8x8_t a) { 448 int8x8_t v; 449 v = a; 450 return v; 451 } 452 </pre> 453 </blockquote> 454 455 <!-- ======================================================================= --> 456 <h3><a name="vector_literals">Vector Literals</a></h3> 457 <!-- ======================================================================= --> 458 459 <p>Vector literals can be used to create vectors from a set of scalars, or 460 vectors. Either parentheses or braces form can be used. In the parentheses form 461 the number of literal values specified must be one, i.e. referring to a scalar 462 value, or must match the size of the vector type being created. If a single 463 scalar literal value is specified, the scalar literal value will be replicated 464 to all the components of the vector type. In the brackets form any number of 465 literals can be specified. For example:</p> 466 467 <blockquote> 468 <pre> 469 typedef int v4si __attribute__((__vector_size__(16))); 470 typedef float float4 __attribute__((ext_vector_type(4))); 471 typedef float float2 __attribute__((ext_vector_type(2))); 472 473 v4si vsi = (v4si){1, 2, 3, 4}; 474 float4 vf = (float4)(1.0f, 2.0f, 3.0f, 4.0f); 475 vector int vi1 = (vector int)(1); // vi1 will be (1, 1, 1, 1). 476 vector int vi2 = (vector int){1}; // vi2 will be (1, 0, 0, 0). 477 vector int vi3 = (vector int)(1, 2); // error 478 vector int vi4 = (vector int){1, 2}; // vi4 will be (1, 2, 0, 0). 479 vector int vi5 = (vector int)(1, 2, 3, 4); 480 float4 vf = (float4)((float2)(1.0f, 2.0f), (float2)(3.0f, 4.0f)); 481 </pre> 482 </blockquote> 483 484 <!-- ======================================================================= --> 485 <h3><a name="vector_operations">Vector Operations</a></h3> 486 <!-- ======================================================================= --> 487 488 <p>The table below shows the support for each operation by vector extension. 489 A dash indicates that an operation is not accepted according to a corresponding 490 specification.</p> 491 492 <table width="500" border="1" cellspacing="0"> 493 <tr> 494 <th>Operator</th> 495 <th>OpenCL</th> 496 <th>AltiVec</th> 497 <th>GCC</th> 498 <th>NEON</th> 499 </tr> 500 <tr> 501 <td>[]</td> 502 <td align="center">yes</td> 503 <td align="center">yes</td> 504 <td align="center">yes</td> 505 <td align="center">-</td> 506 </tr> 507 <tr> 508 <td>unary operators +, -</td> 509 <td align="center">yes</td> 510 <td align="center">yes</td> 511 <td align="center">yes</td> 512 <td align="center">-</td> 513 </tr> 514 <tr> 515 <td>++, --</td> 516 <td align="center">yes</td> 517 <td align="center">yes</td> 518 <td align="center">-</td> 519 <td align="center">-</td> 520 </tr> 521 <tr> 522 <td>+, -, *, /, %</td> 523 <td align="center">yes</td> 524 <td align="center">yes</td> 525 <td align="center">yes</td> 526 <td align="center">-</td> 527 </tr> 528 <tr> 529 <td>bitwise operators &, |, ^, ~</td> 530 <td align="center">yes</td> 531 <td align="center">yes</td> 532 <td align="center">yes</td> 533 <td align="center">-</td> 534 </tr> 535 <tr> 536 <td>>>, <<</td> 537 <td align="center">yes</td> 538 <td align="center">yes</td> 539 <td align="center">yes</td> 540 <td align="center">-</td> 541 </tr> 542 <tr> 543 <td>!, &&,||</td> 544 <td align="center">no</td> 545 <td align="center">-</td> 546 <td align="center">-</td> 547 <td align="center">-</td> 548 </tr> 549 <tr> 550 <td>==,!=, >, <, >=, <=</td> 551 <td align="center">yes</td> 552 <td align="center">yes</td> 553 <td align="center">-</td> 554 <td align="center">-</td> 555 </tr> 556 <tr> 557 <td>=</td> 558 <td align="center">yes</td> 559 <td align="center">yes</td> 560 <td align="center">yes</td> 561 <td align="center">yes</td> 562 </tr> 563 <tr> 564 <td>:?</td> 565 <td align="center">yes</td> 566 <td align="center">-</td> 567 <td align="center">-</td> 568 <td align="center">-</td> 569 </tr> 570 <tr> 571 <td>sizeof</td> 572 <td align="center">yes</td> 573 <td align="center">yes</td> 574 <td align="center">yes</td> 575 <td align="center">yes</td> 576 </tr> 577 </table> 578 579 <p>See also <a href="#__builtin_shufflevector">__builtin_shufflevector</a>.</p> 580 581 <!-- ======================================================================= --> 582 <h2 id="deprecated">Messages on <tt>deprecated</tt> and <tt>unavailable</tt> Attributes</h2> 583 <!-- ======================================================================= --> 584 585 <p>An optional string message can be added to the <tt>deprecated</tt> 586 and <tt>unavailable</tt> attributes. For example:</p> 587 588 <blockquote> 589 <pre>void explode(void) __attribute__((deprecated("extremely unsafe, use 'combust' instead!!!")));</pre> 590 </blockquote> 591 592 <p>If the deprecated or unavailable declaration is used, the message 593 will be incorporated into the appropriate diagnostic:</p> 594 595 <blockquote> 596 <pre>harmless.c:4:3: warning: 'explode' is deprecated: extremely unsafe, use 'combust' instead!!! 597 [-Wdeprecated-declarations] 598 explode(); 599 ^</pre> 600 </blockquote> 601 602 <p>Query for this feature 603 with <tt>__has_extension(attribute_deprecated_with_message)</tt> 604 and <tt>__has_extension(attribute_unavailable_with_message)</tt>.</p> 605 606 <!-- ======================================================================= --> 607 <h2 id="attributes-on-enumerators">Attributes on Enumerators</h2> 608 <!-- ======================================================================= --> 609 610 <p>Clang allows attributes to be written on individual enumerators. 611 This allows enumerators to be deprecated, made unavailable, etc. The 612 attribute must appear after the enumerator name and before any 613 initializer, like so:</p> 614 615 <blockquote> 616 <pre>enum OperationMode { 617 OM_Invalid, 618 OM_Normal, 619 OM_Terrified __attribute__((deprecated)), 620 OM_AbortOnError __attribute__((deprecated)) = 4 621 };</pre> 622 </blockquote> 623 624 <p>Attributes on the <tt>enum</tt> declaration do not apply to 625 individual enumerators.</p> 626 627 <p>Query for this feature with <tt>__has_extension(enumerator_attributes)</tt>.</p> 628 629 <!-- ======================================================================= --> 630 <h2 id="user_specified_system_framework">'User-Specified' System Frameworks</h2> 631 <!-- ======================================================================= --> 632 633 <p>Clang provides a mechanism by which frameworks can be built in such a way 634 that they will always be treated as being 'system frameworks', even if they are 635 not present in a system framework directory. This can be useful to system 636 framework developers who want to be able to test building other applications 637 with development builds of their framework, including the manner in which the 638 compiler changes warning behavior for system headers.</p> 639 640 <p>Framework developers can opt-in to this mechanism by creating a 641 '.system_framework' file at the top-level of their framework. That is, the 642 framework should have contents like:</p> 643 644 <pre> 645 .../TestFramework.framework 646 .../TestFramework.framework/.system_framework 647 .../TestFramework.framework/Headers 648 .../TestFramework.framework/Headers/TestFramework.h 649 ... 650 </pre> 651 652 <p>Clang will treat the presence of this file as an indicator that the framework 653 should be treated as a system framework, regardless of how it was found in the 654 framework search path. For consistency, we recommend that such files never be 655 included in installed versions of the framework.</p> 656 657 <!-- ======================================================================= --> 658 <h2 id="availability">Availability attribute</h2 659 <!-- ======================================================================= --> 660 661 <p>Clang introduces the <code>availability</code> attribute, which can 662 be placed on declarations to describe the lifecycle of that 663 declaration relative to operating system versions. Consider the function declaration for a hypothetical function <code>f</code>:</p> 664 665 <pre> 666 void f(void) __attribute__((availability(macosx,introduced=10.4,deprecated=10.6,obsoleted=10.7))); 667 </pre> 668 669 <p>The availability attribute states that <code>f</code> was introduced in Mac OS X 10.4, deprecated in Mac OS X 10.6, and obsoleted in Mac OS X 10.7. This information is used by Clang to determine when it is safe to use <code>f</code>: for example, if Clang is instructed to compile code for Mac OS X 10.5, a call to <code>f()</code> succeeds. If Clang is instructed to compile code for Mac OS X 10.6, the call succeeds but Clang emits a warning specifying that the function is deprecated. Finally, if Clang is instructed to compile code for Mac OS X 10.7, the call fails because <code>f()</code> is no longer available.</p> 670 671 <p>The availablility attribute is a comma-separated list starting with the platform name and then including clauses specifying important milestones in the declaration's lifetime (in any order) along with additional information. Those clauses can be:</p> 672 673 <dl> 674 <dt>introduced=<i>version</i></dt> 675 <dd>The first version in which this declaration was introduced.</dd> 676 677 <dt>deprecated=<i>version</i></dt> 678 <dd>The first version in which this declaration was deprecated, meaning that users should migrate away from this API.</dd> 679 680 <dt>obsoleted=<i>version</i></dt> 681 <dd>The first version in which this declaration was obsoleted, meaning that it was removed completely and can no longer be used.</dd> 682 683 <dt>unavailable</dt> 684 <dd>This declaration is never available on this platform.</dd> 685 686 <dt>message=<i>string-literal</i></dt> 687 <dd>Additional message text that Clang will provide when emitting a warning or error about use of a deprecated or obsoleted declaration. Useful to direct users to replacement APIs.</dd> 688 </dl> 689 690 <p>Multiple availability attributes can be placed on a declaration, which may correspond to different platforms. Only the availability attribute with the platform corresponding to the target platform will be used; any others will be ignored. If no availability attribute specifies availability for the current target platform, the availability attributes are ignored. Supported platforms are:</p> 691 692 <dl> 693 <dt>ios</dt> 694 <dd>Apple's iOS operating system. The minimum deployment target is specified by the <code>-mios-version-min=<i>version</i></code> or <code>-miphoneos-version-min=<i>version</i></code> command-line arguments.</dd> 695 696 <dt>macosx</dt> 697 <dd>Apple's Mac OS X operating system. The minimum deployment target is specified by the <code>-mmacosx-version-min=<i>version</i></code> command-line argument.</dd> 698 </dl> 699 700 <p>A declaration can be used even when deploying back to a platform 701 version prior to when the declaration was introduced. When this 702 happens, the declaration is <a 703 href="https://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html">weakly 704 linked</a>, as if the <code>weak_import</code> attribute were added to the declaration. A weakly-linked declaration may or may not be present a run-time, and a program can determine whether the declaration is present by checking whether the address of that declaration is non-NULL.</p> 705 706 <!-- ======================================================================= --> 707 <h2 id="checking_language_features">Checks for Standard Language Features</h2> 708 <!-- ======================================================================= --> 709 710 <p>The <tt>__has_feature</tt> macro can be used to query if certain standard 711 language features are enabled. The <tt>__has_extension</tt> macro can be used 712 to query if language features are available as an extension when compiling for 713 a standard which does not provide them. The features which can be tested are 714 listed here.</p> 715 716 <h3 id="cxx98">C++98</h3> 717 718 <p>The features listed below are part of the C++98 standard. These features are 719 enabled by default when compiling C++ code.</p> 720 721 <h4 id="cxx_exceptions">C++ exceptions</h4> 722 723 <p>Use <tt>__has_feature(cxx_exceptions)</tt> to determine if C++ exceptions have been enabled. For 724 example, compiling code with <tt>-fno-exceptions</tt> disables C++ exceptions.</p> 725 726 <h4 id="cxx_rtti">C++ RTTI</h4> 727 728 <p>Use <tt>__has_feature(cxx_rtti)</tt> to determine if C++ RTTI has been enabled. For example, 729 compiling code with <tt>-fno-rtti</tt> disables the use of RTTI.</p> 730 731 <h3 id="cxx11">C++11</h3> 732 733 <p>The features listed below are part of the C++11 standard. As a result, all 734 these features are enabled with the <tt>-std=c++11</tt> or <tt>-std=gnu++11</tt> 735 option when compiling C++ code.</p> 736 737 <h4 id="cxx_access_control_sfinae">C++11 SFINAE includes access control</h4> 738 739 <p>Use <tt>__has_feature(cxx_access_control_sfinae)</tt> or <tt>__has_extension(cxx_access_control_sfinae)</tt> to determine whether access-control errors (e.g., calling a private constructor) are considered to be template argument deduction errors (aka SFINAE errors), per <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1170">C++ DR1170</a>.</p> 740 741 <h4 id="cxx_alias_templates">C++11 alias templates</h4> 742 743 <p>Use <tt>__has_feature(cxx_alias_templates)</tt> or 744 <tt>__has_extension(cxx_alias_templates)</tt> to determine if support for 745 C++11's alias declarations and alias templates is enabled.</p> 746 747 <h4 id="cxx_alignas">C++11 alignment specifiers</h4> 748 749 <p>Use <tt>__has_feature(cxx_alignas)</tt> or 750 <tt>__has_extension(cxx_alignas)</tt> to determine if support for alignment 751 specifiers using <tt>alignas</tt> is enabled.</p> 752 753 <h4 id="cxx_attributes">C++11 attributes</h4> 754 755 <p>Use <tt>__has_feature(cxx_attributes)</tt> or 756 <tt>__has_extension(cxx_attributes)</tt> to determine if support for attribute 757 parsing with C++11's square bracket notation is enabled.</p> 758 759 <h4 id="cxx_constexpr">C++11 generalized constant expressions</h4> 760 761 <p>Use <tt>__has_feature(cxx_constexpr)</tt> to determine if support 762 for generalized constant expressions (e.g., <tt>constexpr</tt>) is 763 enabled.</p> 764 765 <h4 id="cxx_decltype">C++11 <tt>decltype()</tt></h4> 766 767 <p>Use <tt>__has_feature(cxx_decltype)</tt> or 768 <tt>__has_extension(cxx_decltype)</tt> to determine if support for the 769 <tt>decltype()</tt> specifier is enabled. C++11's <tt>decltype</tt> 770 does not require type-completeness of a function call expression. 771 Use <tt>__has_feature(cxx_decltype_incomplete_return_types)</tt> 772 or <tt>__has_extension(cxx_decltype_incomplete_return_types)</tt> 773 to determine if support for this feature is enabled.</p> 774 775 <h4 id="cxx_default_function_template_args">C++11 default template arguments in function templates</h4> 776 777 <p>Use <tt>__has_feature(cxx_default_function_template_args)</tt> or 778 <tt>__has_extension(cxx_default_function_template_args)</tt> to determine 779 if support for default template arguments in function templates is enabled.</p> 780 781 <h4 id="cxx_defaulted_functions">C++11 <tt>default</tt>ed functions</h4> 782 783 <p>Use <tt>__has_feature(cxx_defaulted_functions)</tt> or 784 <tt>__has_extension(cxx_defaulted_functions)</tt> to determine if support for 785 defaulted function definitions (with <tt>= default</tt>) is enabled.</p> 786 787 <h4 id="cxx_delegating_constructors">C++11 delegating constructors</h4> 788 789 <p>Use <tt>__has_feature(cxx_delegating_constructors)</tt> to determine if 790 support for delegating constructors is enabled.</p> 791 792 <h4 id="cxx_deleted_functions">C++11 <tt>delete</tt>d functions</h4> 793 794 <p>Use <tt>__has_feature(cxx_deleted_functions)</tt> or 795 <tt>__has_extension(cxx_deleted_functions)</tt> to determine if support for 796 deleted function definitions (with <tt>= delete</tt>) is enabled.</p> 797 798 <h4 id="cxx_explicit_conversions">C++11 explicit conversion functions</h4> 799 <p>Use <tt>__has_feature(cxx_explicit_conversions)</tt> to determine if support for <tt>explicit</tt> conversion functions is enabled.</p> 800 801 <h4 id="cxx_generalized_initializers">C++11 generalized initializers</h4> 802 803 <p>Use <tt>__has_feature(cxx_generalized_initializers)</tt> to determine if 804 support for generalized initializers (using braced lists and 805 <tt>std::initializer_list</tt>) is enabled.</p> 806 807 <h4 id="cxx_implicit_moves">C++11 implicit move constructors/assignment operators</h4> 808 809 <p>Use <tt>__has_feature(cxx_implicit_moves)</tt> to determine if Clang will 810 implicitly generate move constructors and move assignment operators where needed.</p> 811 812 <h4 id="cxx_inheriting_constructors">C++11 inheriting constructors</h4> 813 814 <p>Use <tt>__has_feature(cxx_inheriting_constructors)</tt> to determine if support for inheriting constructors is enabled. Clang does not currently implement this feature.</p> 815 816 <h4 id="cxx_inline_namespaces">C++11 inline namespaces</h4> 817 818 <p>Use <tt>__has_feature(cxx_inline_namespaces)</tt> or 819 <tt>__has_extension(cxx_inline_namespaces)</tt> to determine if support for 820 inline namespaces is enabled.</p> 821 822 <h4 id="cxx_lambdas">C++11 lambdas</h4> 823 824 <p>Use <tt>__has_feature(cxx_lambdas)</tt> or 825 <tt>__has_extension(cxx_lambdas)</tt> to determine if support for lambdas 826 is enabled. </p> 827 828 <h4 id="cxx_local_type_template_args">C++11 local and unnamed types as template arguments</h4> 829 830 <p>Use <tt>__has_feature(cxx_local_type_template_args)</tt> or 831 <tt>__has_extension(cxx_local_type_template_args)</tt> to determine if 832 support for local and unnamed types as template arguments is enabled.</p> 833 834 <h4 id="cxx_noexcept">C++11 noexcept</h4> 835 836 <p>Use <tt>__has_feature(cxx_noexcept)</tt> or 837 <tt>__has_extension(cxx_noexcept)</tt> to determine if support for noexcept 838 exception specifications is enabled.</p> 839 840 <h4 id="cxx_nonstatic_member_init">C++11 in-class non-static data member initialization</h4> 841 842 <p>Use <tt>__has_feature(cxx_nonstatic_member_init)</tt> to determine whether in-class initialization of non-static data members is enabled.</p> 843 844 <h4 id="cxx_nullptr">C++11 <tt>nullptr</tt></h4> 845 846 <p>Use <tt>__has_feature(cxx_nullptr)</tt> or 847 <tt>__has_extension(cxx_nullptr)</tt> to determine if support for 848 <tt>nullptr</tt> is enabled.</p> 849 850 <h4 id="cxx_override_control">C++11 <tt>override control</tt></h4> 851 852 <p>Use <tt>__has_feature(cxx_override_control)</tt> or 853 <tt>__has_extension(cxx_override_control)</tt> to determine if support for 854 the override control keywords is enabled.</p> 855 856 <h4 id="cxx_reference_qualified_functions">C++11 reference-qualified functions</h4> 857 <p>Use <tt>__has_feature(cxx_reference_qualified_functions)</tt> or 858 <tt>__has_extension(cxx_reference_qualified_functions)</tt> to determine 859 if support for reference-qualified functions (e.g., member functions with 860 <code>&</code> or <code>&&</code> applied to <code>*this</code>) 861 is enabled.</p> 862 863 <h4 id="cxx_range_for">C++11 range-based <tt>for</tt> loop</h4> 864 865 <p>Use <tt>__has_feature(cxx_range_for)</tt> or 866 <tt>__has_extension(cxx_range_for)</tt> to determine if support for the 867 range-based for loop is enabled. </p> 868 869 <h4 id="cxx_raw_string_literals">C++11 raw string literals</h4> 870 <p>Use <tt>__has_feature(cxx_raw_string_literals)</tt> to determine if support 871 for raw string literals (e.g., <tt>R"x(foo\bar)x"</tt>) is enabled.</p> 872 873 <h4 id="cxx_rvalue_references">C++11 rvalue references</h4> 874 875 <p>Use <tt>__has_feature(cxx_rvalue_references)</tt> or 876 <tt>__has_extension(cxx_rvalue_references)</tt> to determine if support for 877 rvalue references is enabled. </p> 878 879 <h4 id="cxx_static_assert">C++11 <tt>static_assert()</tt></h4> 880 881 <p>Use <tt>__has_feature(cxx_static_assert)</tt> or 882 <tt>__has_extension(cxx_static_assert)</tt> to determine if support for 883 compile-time assertions using <tt>static_assert</tt> is enabled.</p> 884 885 <h4 id="cxx_auto_type">C++11 type inference</h4> 886 887 <p>Use <tt>__has_feature(cxx_auto_type)</tt> or 888 <tt>__has_extension(cxx_auto_type)</tt> to determine C++11 type inference is 889 supported using the <tt>auto</tt> specifier. If this is disabled, <tt>auto</tt> 890 will instead be a storage class specifier, as in C or C++98.</p> 891 892 <h4 id="cxx_strong_enums">C++11 strongly typed enumerations</h4> 893 894 <p>Use <tt>__has_feature(cxx_strong_enums)</tt> or 895 <tt>__has_extension(cxx_strong_enums)</tt> to determine if support for 896 strongly typed, scoped enumerations is enabled.</p> 897 898 <h4 id="cxx_trailing_return">C++11 trailing return type</h4> 899 900 <p>Use <tt>__has_feature(cxx_trailing_return)</tt> or 901 <tt>__has_extension(cxx_trailing_return)</tt> to determine if support for the 902 alternate function declaration syntax with trailing return type is enabled.</p> 903 904 <h4 id="cxx_unicode_literals">C++11 Unicode string literals</h4> 905 <p>Use <tt>__has_feature(cxx_unicode_literals)</tt> to determine if 906 support for Unicode string literals is enabled.</p> 907 908 <h4 id="cxx_unrestricted_unions">C++11 unrestricted unions</h4> 909 910 <p>Use <tt>__has_feature(cxx_unrestricted_unions)</tt> to determine if support for unrestricted unions is enabled.</p> 911 912 <h4 id="cxx_user_literals">C++11 user-defined literals</h4> 913 914 <p>Use <tt>__has_feature(cxx_user_literals)</tt> to determine if support for user-defined literals is enabled.</p> 915 916 <h4 id="cxx_variadic_templates">C++11 variadic templates</h4> 917 918 <p>Use <tt>__has_feature(cxx_variadic_templates)</tt> or 919 <tt>__has_extension(cxx_variadic_templates)</tt> to determine if support 920 for variadic templates is enabled.</p> 921 922 <h3 id="c11">C11</h3> 923 924 <p>The features listed below are part of the C11 standard. As a result, all 925 these features are enabled with the <tt>-std=c11</tt> or <tt>-std=gnu11</tt> 926 option when compiling C code. Additionally, because these features are all 927 backward-compatible, they are available as extensions in all language modes.</p> 928 929 <h4 id="c_alignas">C11 alignment specifiers</h4> 930 931 <p>Use <tt>__has_feature(c_alignas)</tt> or <tt>__has_extension(c_alignas)</tt> 932 to determine if support for alignment specifiers using <tt>_Alignas</tt> 933 is enabled.</p> 934 935 <h4 id="c_atomic">C11 atomic operations</h4> 936 937 <p>Use <tt>__has_feature(c_atomic)</tt> or <tt>__has_extension(c_atomic)</tt> 938 to determine if support for atomic types using <tt>_Atomic</tt> is enabled. 939 Clang also provides <a href="#__c11_atomic">a set of builtins</a> which can be 940 used to implement the <tt><stdatomic.h></tt> operations on _Atomic 941 types.</p> 942 943 <h4 id="c_generic_selections">C11 generic selections</h4> 944 945 <p>Use <tt>__has_feature(c_generic_selections)</tt> or 946 <tt>__has_extension(c_generic_selections)</tt> to determine if support for 947 generic selections is enabled.</p> 948 949 <p>As an extension, the C11 generic selection expression is available in all 950 languages supported by Clang. The syntax is the same as that given in the 951 C11 standard.</p> 952 953 <p>In C, type compatibility is decided according to the rules given in the 954 appropriate standard, but in C++, which lacks the type compatibility rules 955 used in C, types are considered compatible only if they are equivalent.</p> 956 957 <h4 id="c_static_assert">C11 <tt>_Static_assert()</tt></h4> 958 959 <p>Use <tt>__has_feature(c_static_assert)</tt> or 960 <tt>__has_extension(c_static_assert)</tt> to determine if support for 961 compile-time assertions using <tt>_Static_assert</tt> is enabled.</p> 962 963 <!-- ======================================================================= --> 964 <h2 id="checking_type_traits">Checks for Type Traits</h2> 965 <!-- ======================================================================= --> 966 967 <p>Clang supports the <a href="http://gcc.gnu.org/onlinedocs/gcc/Type-Traits.html">GNU C++ type traits</a> and a subset of the <a href="http://msdn.microsoft.com/en-us/library/ms177194(v=VS.100).aspx">Microsoft Visual C++ Type traits</a>. For each supported type trait <code>__X</code>, <code>__has_extension(X)</code> indicates the presence of the type trait. For example: 968 <blockquote> 969 <pre> 970 #if __has_extension(is_convertible_to) 971 template<typename From, typename To> 972 struct is_convertible_to { 973 static const bool value = __is_convertible_to(From, To); 974 }; 975 #else 976 // Emulate type trait 977 #endif 978 </pre> 979 </blockquote> 980 981 <p>The following type traits are supported by Clang:</p> 982 <ul> 983 <li><code>__has_nothrow_assign</code> (GNU, Microsoft)</li> 984 <li><code>__has_nothrow_copy</code> (GNU, Microsoft)</li> 985 <li><code>__has_nothrow_constructor</code> (GNU, Microsoft)</li> 986 <li><code>__has_trivial_assign</code> (GNU, Microsoft)</li> 987 <li><code>__has_trivial_copy</code> (GNU, Microsoft)</li> 988 <li><code>__has_trivial_constructor</code> (GNU, Microsoft)</li> 989 <li><code>__has_trivial_destructor</code> (GNU, Microsoft)</li> 990 <li><code>__has_virtual_destructor</code> (GNU, Microsoft)</li> 991 <li><code>__is_abstract</code> (GNU, Microsoft)</li> 992 <li><code>__is_base_of</code> (GNU, Microsoft)</li> 993 <li><code>__is_class</code> (GNU, Microsoft)</li> 994 <li><code>__is_convertible_to</code> (Microsoft)</li> 995 <li><code>__is_empty</code> (GNU, Microsoft)</li> 996 <li><code>__is_enum</code> (GNU, Microsoft)</li> 997 <li><code>__is_pod</code> (GNU, Microsoft)</li> 998 <li><code>__is_polymorphic</code> (GNU, Microsoft)</li> 999 <li><code>__is_union</code> (GNU, Microsoft)</li> 1000 <li><code>__is_literal(type)</code>: Determines whether the given type is a literal type</li> 1001 <li><code>__is_final</code>: Determines whether the given type is declared with a <code>final</code> class-virt-specifier.</li> 1002 <li><code>__underlying_type(type)</code>: Retrieves the underlying type for a given <code>enum</code> type. This trait is required to implement the C++11 standard library.</li> 1003 <li><code>__is_trivially_assignable(totype, fromtype)</code>: Determines whether a value of type <tt>totype</tt> can be assigned to from a value of type <tt>fromtype</tt> such that no non-trivial functions are called as part of that assignment. This trait is required to implement the C++11 standard library.</li> 1004 <li><code>__is_trivially_constructible(type, argtypes...)</code>: Determines whether a value of type <tt>type</tt> can be direct-initialized with arguments of types <tt>argtypes...</tt> such that no non-trivial functions are called as part of that initialization. This trait is required to implement the C++11 standard library.</li> 1005 </ul> 1006 1007 <!-- ======================================================================= --> 1008 <h2 id="blocks">Blocks</h2> 1009 <!-- ======================================================================= --> 1010 1011 <p>The syntax and high level language feature description is in <a 1012 href="BlockLanguageSpec.txt">BlockLanguageSpec.txt</a>. Implementation and ABI 1013 details for the clang implementation are in <a 1014 href="Block-ABI-Apple.txt">Block-ABI-Apple.txt</a>.</p> 1015 1016 1017 <p>Query for this feature with __has_extension(blocks).</p> 1018 1019 <!-- ======================================================================= --> 1020 <h2 id="objc_features">Objective-C Features</h2> 1021 <!-- ======================================================================= --> 1022 1023 <h3 id="objc_instancetype">Related result types</h3> 1024 1025 <p>According to Cocoa conventions, Objective-C methods with certain names ("init", "alloc", etc.) always return objects that are an instance of the receiving class's type. Such methods are said to have a "related result type", meaning that a message send to one of these methods will have the same static type as an instance of the receiver class. For example, given the following classes:</p> 1026 1027 <blockquote> 1028 <pre> 1029 @interface NSObject 1030 + (id)alloc; 1031 - (id)init; 1032 @end 1033 1034 @interface NSArray : NSObject 1035 @end 1036 </pre> 1037 </blockquote> 1038 1039 <p>and this common initialization pattern</p> 1040 1041 <blockquote> 1042 <pre> 1043 NSArray *array = [[NSArray alloc] init]; 1044 </pre> 1045 </blockquote> 1046 1047 <p>the type of the expression <code>[NSArray alloc]</code> is 1048 <code>NSArray*</code> because <code>alloc</code> implicitly has a 1049 related result type. Similarly, the type of the expression 1050 <code>[[NSArray alloc] init]</code> is <code>NSArray*</code>, since 1051 <code>init</code> has a related result type and its receiver is known 1052 to have the type <code>NSArray *</code>. If neither <code>alloc</code> nor <code>init</code> had a related result type, the expressions would have had type <code>id</code>, as declared in the method signature.</p> 1053 1054 <p>A method with a related result type can be declared by using the 1055 type <tt>instancetype</tt> as its result type. <tt>instancetype</tt> 1056 is a contextual keyword that is only permitted in the result type of 1057 an Objective-C method, e.g.</p> 1058 1059 <pre> 1060 @interface A 1061 + (<b>instancetype</b>)constructAnA; 1062 @end 1063 </pre> 1064 1065 <p>The related result type can also be inferred for some methods. 1066 To determine whether a method has an inferred related result type, the first 1067 word in the camel-case selector (e.g., "init" in "initWithObjects") is 1068 considered, and the method will have a related result type if its return 1069 type is compatible with the type of its class and if</p> 1070 1071 <ul> 1072 1073 <li>the first word is "alloc" or "new", and the method is a class 1074 method, or</li> 1075 1076 <li>the first word is "autorelease", "init", "retain", or "self", 1077 and the method is an instance method.</li> 1078 1079 </ul> 1080 1081 <p>If a method with a related result type is overridden by a subclass 1082 method, the subclass method must also return a type that is compatible 1083 with the subclass type. For example:</p> 1084 1085 <blockquote> 1086 <pre> 1087 @interface NSString : NSObject 1088 - (NSUnrelated *)init; // incorrect usage: NSUnrelated is not NSString or a superclass of NSString 1089 @end 1090 </pre> 1091 </blockquote> 1092 1093 <p>Related result types only affect the type of a message send or 1094 property access via the given method. In all other respects, a method 1095 with a related result type is treated the same way as method that 1096 returns <tt>id</tt>.</p> 1097 1098 <p>Use <tt>__has_feature(objc_instancetype)</tt> to determine whether 1099 the <tt>instancetype</tt> contextual keyword is available.</p> 1100 1101 <!-- ======================================================================= --> 1102 <h2 id="objc_arc">Automatic reference counting </h2> 1103 <!-- ======================================================================= --> 1104 1105 <p>Clang provides support for <a href="AutomaticReferenceCounting.html">automated reference counting</a> in Objective-C, which eliminates the need for manual retain/release/autorelease message sends. There are two feature macros associated with automatic reference counting: <code>__has_feature(objc_arc)</code> indicates the availability of automated reference counting in general, while <code>__has_feature(objc_arc_weak)</code> indicates that automated reference counting also includes support for <code>__weak</code> pointers to Objective-C objects.</p> 1106 1107 <!-- ======================================================================= --> 1108 <h2 id="objc_fixed_enum">Enumerations with a fixed underlying type</h2> 1109 <!-- ======================================================================= --> 1110 1111 <p>Clang provides support for C++11 enumerations with a fixed 1112 underlying type within Objective-C. For example, one can write an 1113 enumeration type as:</p> 1114 1115 <pre> 1116 typedef enum : unsigned char { Red, Green, Blue } Color; 1117 </pre> 1118 1119 <p>This specifies that the underlying type, which is used to store the 1120 enumeration value, is <tt>unsigned char</tt>.</p> 1121 1122 <p>Use <tt>__has_feature(objc_fixed_enum)</tt> to determine whether 1123 support for fixed underlying types is available in Objective-C.</p> 1124 1125 <!-- ======================================================================= --> 1126 <h2 id="objc_lambdas">Interoperability with C++11 lambdas</h2> 1127 <!-- ======================================================================= --> 1128 1129 <p>Clang provides interoperability between C++11 lambdas and 1130 blocks-based APIs, by permitting a lambda to be implicitly converted 1131 to a block pointer with the corresponding signature. For example, 1132 consider an API such as <code>NSArray</code>'s array-sorting 1133 method:</p> 1134 1135 <pre> - (NSArray *)sortedArrayUsingComparator:(NSComparator)cmptr; </pre> 1136 1137 <p><code>NSComparator</code> is simply a typedef for the block pointer 1138 <code>NSComparisonResult (^)(id, id)</code>, and parameters of this 1139 type are generally provided with block literals as arguments. However, 1140 one can also use a C++11 lambda so long as it provides the same 1141 signature (in this case, accepting two parameters of type 1142 <code>id</code> and returning an <code>NSComparisonResult</code>):</p> 1143 1144 <pre> 1145 NSArray *array = @[@"string 1", @"string 21", @"string 12", @"String 11", 1146 @"String 02"]; 1147 const NSStringCompareOptions comparisonOptions 1148 = NSCaseInsensitiveSearch | NSNumericSearch | 1149 NSWidthInsensitiveSearch | NSForcedOrderingSearch; 1150 NSLocale *currentLocale = [NSLocale currentLocale]; 1151 NSArray *sorted 1152 = [array sortedArrayUsingComparator:<b>[=](id s1, id s2) -> NSComparisonResult { 1153 NSRange string1Range = NSMakeRange(0, [s1 length]); 1154 return [s1 compare:s2 options:comparisonOptions 1155 range:string1Range locale:currentLocale]; 1156 }</b>]; 1157 NSLog(@"sorted: %@", sorted); 1158 </pre> 1159 1160 <p>This code relies on an implicit conversion from the type of the 1161 lambda expression (an unnamed, local class type called the <i>closure 1162 type</i>) to the corresponding block pointer type. The conversion 1163 itself is expressed by a conversion operator in that closure type 1164 that produces a block pointer with the same signature as the lambda 1165 itself, e.g.,</p> 1166 1167 <pre> 1168 operator NSComparisonResult (^)(id, id)() const; 1169 </pre> 1170 1171 <p>This conversion function returns a new block that simply forwards 1172 the two parameters to the lambda object (which it captures by copy), 1173 then returns the result. The returned block is first copied (with 1174 <tt>Block_copy</tt>) and then autoreleased. As an optimization, if a 1175 lambda expression is immediately converted to a block pointer (as in 1176 the first example, above), then the block is not copied and 1177 autoreleased: rather, it is given the same lifetime as a block literal 1178 written at that point in the program, which avoids the overhead of 1179 copying a block to the heap in the common case.</p> 1180 1181 <p>The conversion from a lambda to a block pointer is only available 1182 in Objective-C++, and not in C++ with blocks, due to its use of 1183 Objective-C memory management (autorelease).</p> 1184 1185 <!-- ======================================================================= --> 1186 <h2 id="objc_object_literals_subscripting">Object Literals and Subscripting</h2> 1187 <!-- ======================================================================= --> 1188 1189 <p>Clang provides support for <a href="ObjectiveCLiterals.html">Object Literals 1190 and Subscripting</a> in Objective-C, which simplifies common Objective-C 1191 programming patterns, makes programs more concise, and improves the safety of 1192 container creation. There are several feature macros associated with object 1193 literals and subscripting: <code>__has_feature(objc_array_literals)</code> 1194 tests the availability of array literals; 1195 <code>__has_feature(objc_dictionary_literals)</code> tests the availability of 1196 dictionary literals; <code>__has_feature(objc_subscripting)</code> tests the 1197 availability of object subscripting.</p> 1198 1199 <!-- ======================================================================= --> 1200 <h2 id="overloading-in-c">Function Overloading in C</h2> 1201 <!-- ======================================================================= --> 1202 1203 <p>Clang provides support for C++ function overloading in C. Function 1204 overloading in C is introduced using the <tt>overloadable</tt> attribute. For 1205 example, one might provide several overloaded versions of a <tt>tgsin</tt> 1206 function that invokes the appropriate standard function computing the sine of a 1207 value with <tt>float</tt>, <tt>double</tt>, or <tt>long double</tt> 1208 precision:</p> 1209 1210 <blockquote> 1211 <pre> 1212 #include <math.h> 1213 float <b>__attribute__((overloadable))</b> tgsin(float x) { return sinf(x); } 1214 double <b>__attribute__((overloadable))</b> tgsin(double x) { return sin(x); } 1215 long double <b>__attribute__((overloadable))</b> tgsin(long double x) { return sinl(x); } 1216 </pre> 1217 </blockquote> 1218 1219 <p>Given these declarations, one can call <tt>tgsin</tt> with a 1220 <tt>float</tt> value to receive a <tt>float</tt> result, with a 1221 <tt>double</tt> to receive a <tt>double</tt> result, etc. Function 1222 overloading in C follows the rules of C++ function overloading to pick 1223 the best overload given the call arguments, with a few C-specific 1224 semantics:</p> 1225 <ul> 1226 <li>Conversion from <tt>float</tt> or <tt>double</tt> to <tt>long 1227 double</tt> is ranked as a floating-point promotion (per C99) rather 1228 than as a floating-point conversion (as in C++).</li> 1229 1230 <li>A conversion from a pointer of type <tt>T*</tt> to a pointer of type 1231 <tt>U*</tt> is considered a pointer conversion (with conversion 1232 rank) if <tt>T</tt> and <tt>U</tt> are compatible types.</li> 1233 1234 <li>A conversion from type <tt>T</tt> to a value of type <tt>U</tt> 1235 is permitted if <tt>T</tt> and <tt>U</tt> are compatible types. This 1236 conversion is given "conversion" rank.</li> 1237 </ul> 1238 1239 <p>The declaration of <tt>overloadable</tt> functions is restricted to 1240 function declarations and definitions. Most importantly, if any 1241 function with a given name is given the <tt>overloadable</tt> 1242 attribute, then all function declarations and definitions with that 1243 name (and in that scope) must have the <tt>overloadable</tt> 1244 attribute. This rule even applies to redeclarations of functions whose original 1245 declaration had the <tt>overloadable</tt> attribute, e.g.,</p> 1246 1247 <blockquote> 1248 <pre> 1249 int f(int) __attribute__((overloadable)); 1250 float f(float); <i>// error: declaration of "f" must have the "overloadable" attribute</i> 1251 1252 int g(int) __attribute__((overloadable)); 1253 int g(int) { } <i>// error: redeclaration of "g" must also have the "overloadable" attribute</i> 1254 </pre> 1255 </blockquote> 1256 1257 <p>Functions marked <tt>overloadable</tt> must have 1258 prototypes. Therefore, the following code is ill-formed:</p> 1259 1260 <blockquote> 1261 <pre> 1262 int h() __attribute__((overloadable)); <i>// error: h does not have a prototype</i> 1263 </pre> 1264 </blockquote> 1265 1266 <p>However, <tt>overloadable</tt> functions are allowed to use a 1267 ellipsis even if there are no named parameters (as is permitted in C++). This feature is particularly useful when combined with the <tt>unavailable</tt> attribute:</p> 1268 1269 <blockquote> 1270 <pre> 1271 void honeypot(...) __attribute__((overloadable, unavailable)); <i>// calling me is an error</i> 1272 </pre> 1273 </blockquote> 1274 1275 <p>Functions declared with the <tt>overloadable</tt> attribute have 1276 their names mangled according to the same rules as C++ function 1277 names. For example, the three <tt>tgsin</tt> functions in our 1278 motivating example get the mangled names <tt>_Z5tgsinf</tt>, 1279 <tt>_Z5tgsind</tt>, and <tt>_Z5tgsine</tt>, respectively. There are two 1280 caveats to this use of name mangling:</p> 1281 1282 <ul> 1283 1284 <li>Future versions of Clang may change the name mangling of 1285 functions overloaded in C, so you should not depend on an specific 1286 mangling. To be completely safe, we strongly urge the use of 1287 <tt>static inline</tt> with <tt>overloadable</tt> functions.</li> 1288 1289 <li>The <tt>overloadable</tt> attribute has almost no meaning when 1290 used in C++, because names will already be mangled and functions are 1291 already overloadable. However, when an <tt>overloadable</tt> 1292 function occurs within an <tt>extern "C"</tt> linkage specification, 1293 it's name <i>will</i> be mangled in the same way as it would in 1294 C.</li> 1295 </ul> 1296 1297 <p>Query for this feature with __has_extension(attribute_overloadable).</p> 1298 1299 <!-- ======================================================================= --> 1300 <h2 id="complex-list-init">Initializer lists for complex numbers in C</h2> 1301 <!-- ======================================================================= --> 1302 1303 <p>clang supports an extension which allows the following in C:</p> 1304 1305 <blockquote> 1306 <pre> 1307 #include <math.h> 1308 #include <complex.h> 1309 complex float x = { 1.0f, INFINITY }; // Init to (1, Inf) 1310 </pre> 1311 </blockquote> 1312 1313 <p>This construct is useful because there is no way to separately 1314 initialize the real and imaginary parts of a complex variable in 1315 standard C, given that clang does not support <code>_Imaginary</code>. 1316 (clang also supports the <code>__real__</code> and <code>__imag__</code> 1317 extensions from gcc, which help in some cases, but are not usable in 1318 static initializers.) 1319 1320 <p>Note that this extension does not allow eliding the braces; the 1321 meaning of the following two lines is different:</p> 1322 1323 <blockquote> 1324 <pre> 1325 complex float x[] = { { 1.0f, 1.0f } }; // [0] = (1, 1) 1326 complex float x[] = { 1.0f, 1.0f }; // [0] = (1, 0), [1] = (1, 0) 1327 </pre> 1328 </blockquote> 1329 1330 <p>This extension also works in C++ mode, as far as that goes, but does not 1331 apply to the C++ <code>std::complex</code>. (In C++11, list 1332 initialization allows the same syntax to be used with 1333 <code>std::complex</code> with the same meaning.) 1334 1335 <!-- ======================================================================= --> 1336 <h2 id="builtins">Builtin Functions</h2> 1337 <!-- ======================================================================= --> 1338 1339 <p>Clang supports a number of builtin library functions with the same syntax as 1340 GCC, including things like <tt>__builtin_nan</tt>, 1341 <tt>__builtin_constant_p</tt>, <tt>__builtin_choose_expr</tt>, 1342 <tt>__builtin_types_compatible_p</tt>, <tt>__sync_fetch_and_add</tt>, etc. In 1343 addition to the GCC builtins, Clang supports a number of builtins that GCC does 1344 not, which are listed here.</p> 1345 1346 <p>Please note that Clang does not and will not support all of the GCC builtins 1347 for vector operations. Instead of using builtins, you should use the functions 1348 defined in target-specific header files like <tt><xmmintrin.h></tt>, which 1349 define portable wrappers for these. Many of the Clang versions of these 1350 functions are implemented directly in terms of <a href="#vectors">extended 1351 vector support</a> instead of builtins, in order to reduce the number of 1352 builtins that we need to implement.</p> 1353 1354 <!-- ======================================================================= --> 1355 <h3><a name="__builtin_shufflevector">__builtin_shufflevector</a></h3> 1356 <!-- ======================================================================= --> 1357 1358 <p><tt>__builtin_shufflevector</tt> is used to express generic vector 1359 permutation/shuffle/swizzle operations. This builtin is also very important for 1360 the implementation of various target-specific header files like 1361 <tt><xmmintrin.h></tt>. 1362 </p> 1363 1364 <p><b>Syntax:</b></p> 1365 1366 <pre> 1367 __builtin_shufflevector(vec1, vec2, index1, index2, ...) 1368 </pre> 1369 1370 <p><b>Examples:</b></p> 1371 1372 <pre> 1373 // Identity operation - return 4-element vector V1. 1374 __builtin_shufflevector(V1, V1, 0, 1, 2, 3) 1375 1376 // "Splat" element 0 of V1 into a 4-element result. 1377 __builtin_shufflevector(V1, V1, 0, 0, 0, 0) 1378 1379 // Reverse 4-element vector V1. 1380 __builtin_shufflevector(V1, V1, 3, 2, 1, 0) 1381 1382 // Concatenate every other element of 4-element vectors V1 and V2. 1383 __builtin_shufflevector(V1, V2, 0, 2, 4, 6) 1384 1385 // Concatenate every other element of 8-element vectors V1 and V2. 1386 __builtin_shufflevector(V1, V2, 0, 2, 4, 6, 8, 10, 12, 14) 1387 </pre> 1388 1389 <p><b>Description:</b></p> 1390 1391 <p>The first two arguments to __builtin_shufflevector are vectors that have the 1392 same element type. The remaining arguments are a list of integers that specify 1393 the elements indices of the first two vectors that should be extracted and 1394 returned in a new vector. These element indices are numbered sequentially 1395 starting with the first vector, continuing into the second vector. Thus, if 1396 vec1 is a 4-element vector, index 5 would refer to the second element of vec2. 1397 </p> 1398 1399 <p>The result of __builtin_shufflevector is a vector 1400 with the same element type as vec1/vec2 but that has an element count equal to 1401 the number of indices specified. 1402 </p> 1403 1404 <p>Query for this feature with __has_builtin(__builtin_shufflevector).</p> 1405 1406 <!-- ======================================================================= --> 1407 <h3><a name="__builtin_unreachable">__builtin_unreachable</a></h3> 1408 <!-- ======================================================================= --> 1409 1410 <p><tt>__builtin_unreachable</tt> is used to indicate that a specific point in 1411 the program cannot be reached, even if the compiler might otherwise think it 1412 can. This is useful to improve optimization and eliminates certain warnings. 1413 For example, without the <tt>__builtin_unreachable</tt> in the example below, 1414 the compiler assumes that the inline asm can fall through and prints a "function 1415 declared 'noreturn' should not return" warning. 1416 </p> 1417 1418 <p><b>Syntax:</b></p> 1419 1420 <pre> 1421 __builtin_unreachable() 1422 </pre> 1423 1424 <p><b>Example of Use:</b></p> 1425 1426 <pre> 1427 void myabort(void) __attribute__((noreturn)); 1428 void myabort(void) { 1429 asm("int3"); 1430 __builtin_unreachable(); 1431 } 1432 </pre> 1433 1434 <p><b>Description:</b></p> 1435 1436 <p>The __builtin_unreachable() builtin has completely undefined behavior. Since 1437 it has undefined behavior, it is a statement that it is never reached and the 1438 optimizer can take advantage of this to produce better code. This builtin takes 1439 no arguments and produces a void result. 1440 </p> 1441 1442 <p>Query for this feature with __has_builtin(__builtin_unreachable).</p> 1443 1444 <!-- ======================================================================= --> 1445 <h3><a name="__sync_swap">__sync_swap</a></h3> 1446 <!-- ======================================================================= --> 1447 1448 <p><tt>__sync_swap</tt> is used to atomically swap integers or pointers in 1449 memory. 1450 </p> 1451 1452 <p><b>Syntax:</b></p> 1453 1454 <pre> 1455 <i>type</i> __sync_swap(<i>type</i> *ptr, <i>type</i> value, ...) 1456 </pre> 1457 1458 <p><b>Example of Use:</b></p> 1459 1460 <pre> 1461 int old_value = __sync_swap(&value, new_value); 1462 </pre> 1463 1464 <p><b>Description:</b></p> 1465 1466 <p>The __sync_swap() builtin extends the existing __sync_*() family of atomic 1467 intrinsics to allow code to atomically swap the current value with the new 1468 value. More importantly, it helps developers write more efficient and correct 1469 code by avoiding expensive loops around __sync_bool_compare_and_swap() or 1470 relying on the platform specific implementation details of 1471 __sync_lock_test_and_set(). The __sync_swap() builtin is a full barrier. 1472 </p> 1473 1474 <!-- ======================================================================= --> 1475 <h3><a name="__c11_atomic">__c11_atomic builtins</a></h3> 1476 <!-- ======================================================================= --> 1477 1478 <p>Clang provides a set of builtins which are intended to be used to implement 1479 C11's <tt><stdatomic.h></tt> header. These builtins provide the semantics 1480 of the <tt>_explicit</tt> form of the corresponding C11 operation, and are named 1481 with a <tt>__c11_</tt> prefix. The supported operations are:</p> 1482 1483 <ul> 1484 <li><tt>__c11_atomic_init</tt></li> 1485 <li><tt>__c11_atomic_thread_fence</tt></li> 1486 <li><tt>__c11_atomic_signal_fence</tt></li> 1487 <li><tt>__c11_atomic_is_lock_free</tt></li> 1488 <li><tt>__c11_atomic_store</tt></li> 1489 <li><tt>__c11_atomic_load</tt></li> 1490 <li><tt>__c11_atomic_exchange</tt></li> 1491 <li><tt>__c11_atomic_compare_exchange_strong</tt></li> 1492 <li><tt>__c11_atomic_compare_exchange_weak</tt></li> 1493 <li><tt>__c11_atomic_fetch_add</tt></li> 1494 <li><tt>__c11_atomic_fetch_sub</tt></li> 1495 <li><tt>__c11_atomic_fetch_and</tt></li> 1496 <li><tt>__c11_atomic_fetch_or</tt></li> 1497 <li><tt>__c11_atomic_fetch_xor</tt></li> 1498 </ul> 1499 1500 1501 <!-- ======================================================================= --> 1502 <h2 id="targetspecific">Target-Specific Extensions</h2> 1503 <!-- ======================================================================= --> 1504 1505 <p>Clang supports some language features conditionally on some targets.</p> 1506 1507 <!-- ======================================================================= --> 1508 <h3 id="x86-specific">X86/X86-64 Language Extensions</h3> 1509 <!-- ======================================================================= --> 1510 1511 <p>The X86 backend has these language extensions:</p> 1512 1513 <!-- ======================================================================= --> 1514 <h4 id="x86-gs-segment">Memory references off the GS segment</h4> 1515 <!-- ======================================================================= --> 1516 1517 <p>Annotating a pointer with address space #256 causes it to be code generated 1518 relative to the X86 GS segment register, and address space #257 causes it to be 1519 relative to the X86 FS segment. Note that this is a very very low-level 1520 feature that should only be used if you know what you're doing (for example in 1521 an OS kernel).</p> 1522 1523 <p>Here is an example:</p> 1524 1525 <pre> 1526 #define GS_RELATIVE __attribute__((address_space(256))) 1527 int foo(int GS_RELATIVE *P) { 1528 return *P; 1529 } 1530 </pre> 1531 1532 <p>Which compiles to (on X86-32):</p> 1533 1534 <pre> 1535 _foo: 1536 movl 4(%esp), %eax 1537 movl %gs:(%eax), %eax 1538 ret 1539 </pre> 1540 1541 <!-- ======================================================================= --> 1542 <h2 id="analyzerspecific">Static Analysis-Specific Extensions</h2> 1543 <!-- ======================================================================= --> 1544 1545 <p>Clang supports additional attributes that are useful for documenting program 1546 invariants and rules for static analysis tools. The extensions documented here 1547 are used by the <a 1548 href="http://clang.llvm.org/StaticAnalysis.html">path-sensitive static analyzer 1549 engine</a> that is part of Clang's Analysis library.</p> 1550 1551 <h3 id="attr_analyzer_noreturn">The <tt>analyzer_noreturn</tt> attribute</h3> 1552 1553 <p>Clang's static analysis engine understands the standard <tt>noreturn</tt> 1554 attribute. This attribute, which is typically affixed to a function prototype, 1555 indicates that a call to a given function never returns. Function prototypes for 1556 common functions like <tt>exit</tt> are typically annotated with this attribute, 1557 as well as a variety of common assertion handlers. Users can educate the static 1558 analyzer about their own custom assertion handles (thus cutting down on false 1559 positives due to false paths) by marking their own "panic" functions 1560 with this attribute.</p> 1561 1562 <p>While useful, <tt>noreturn</tt> is not applicable in all cases. Sometimes 1563 there are special functions that for all intents and purposes should be 1564 considered panic functions (i.e., they are only called when an internal program 1565 error occurs) but may actually return so that the program can fail gracefully. 1566 The <tt>analyzer_noreturn</tt> attribute allows one to annotate such functions 1567 as being interpreted as "no return" functions by the analyzer (thus 1568 pruning bogus paths) but will not affect compilation (as in the case of 1569 <tt>noreturn</tt>).</p> 1570 1571 <p><b>Usage</b>: The <tt>analyzer_noreturn</tt> attribute can be placed in the 1572 same places where the <tt>noreturn</tt> attribute can be placed. It is commonly 1573 placed at the end of function prototypes:</p> 1574 1575 <pre> 1576 void foo() <b>__attribute__((analyzer_noreturn))</b>; 1577 </pre> 1578 1579 <p>Query for this feature with 1580 <tt>__has_attribute(analyzer_noreturn)</tt>.</p> 1581 1582 <h3 id="attr_method_family">The <tt>objc_method_family</tt> attribute</h3> 1583 1584 <p>Many methods in Objective-C have conventional meanings determined 1585 by their selectors. For the purposes of static analysis, it is 1586 sometimes useful to be able to mark a method as having a particular 1587 conventional meaning despite not having the right selector, or as not 1588 having the conventional meaning that its selector would suggest. 1589 For these use cases, we provide an attribute to specifically describe 1590 the <q>method family</q> that a method belongs to.</p> 1591 1592 <p><b>Usage</b>: <tt>__attribute__((objc_method_family(X)))</tt>, 1593 where <tt>X</tt> is one of <tt>none</tt>, <tt>alloc</tt>, <tt>copy</tt>, 1594 <tt>init</tt>, <tt>mutableCopy</tt>, or <tt>new</tt>. This attribute 1595 can only be placed at the end of a method declaration:</p> 1596 1597 <pre> 1598 - (NSString*) initMyStringValue <b>__attribute__((objc_method_family(none)))</b>; 1599 </pre> 1600 1601 <p>Users who do not wish to change the conventional meaning of a 1602 method, and who merely want to document its non-standard retain and 1603 release semantics, should use the 1604 <a href="#attr_retain_release">retaining behavior attributes</a> 1605 described below.</p> 1606 1607 <p>Query for this feature with 1608 <tt>__has_attribute(objc_method_family)</tt>.</p> 1609 1610 <h3 id="attr_retain_release">Objective-C retaining behavior attributes</h3> 1611 1612 <p>In Objective-C, functions and methods are generally assumed to take 1613 and return objects with +0 retain counts, with some exceptions for 1614 special methods like <tt>+alloc</tt> and <tt>init</tt>. However, 1615 there are exceptions, and so Clang provides attributes to allow these 1616 exceptions to be documented, which helps the analyzer find leaks (and 1617 ignore non-leaks). Some exceptions may be better described using 1618 the <a href="#attr_method_family"><tt>objc_method_family</tt></a> 1619 attribute instead.</p> 1620 1621 <p><b>Usage</b>: The <tt>ns_returns_retained</tt>, <tt>ns_returns_not_retained</tt>, 1622 <tt>ns_returns_autoreleased</tt>, <tt>cf_returns_retained</tt>, 1623 and <tt>cf_returns_not_retained</tt> attributes can be placed on 1624 methods and functions that return Objective-C or CoreFoundation 1625 objects. They are commonly placed at the end of a function prototype 1626 or method declaration:</p> 1627 1628 <pre> 1629 id foo() <b>__attribute__((ns_returns_retained))</b>; 1630 1631 - (NSString*) bar: (int) x <b>__attribute__((ns_returns_retained))</b>; 1632 </pre> 1633 1634 <p>The <tt>*_returns_retained</tt> attributes specify that the 1635 returned object has a +1 retain count. 1636 The <tt>*_returns_not_retained</tt> attributes specify that the return 1637 object has a +0 retain count, even if the normal convention for its 1638 selector would be +1. <tt>ns_returns_autoreleased</tt> specifies that the 1639 returned object is +0, but is guaranteed to live at least as long as the 1640 next flush of an autorelease pool.</p> 1641 1642 <p><b>Usage</b>: The <tt>ns_consumed</tt> and <tt>cf_consumed</tt> 1643 attributes can be placed on an parameter declaration; they specify 1644 that the argument is expected to have a +1 retain count, which will be 1645 balanced in some way by the function or method. 1646 The <tt>ns_consumes_self</tt> attribute can only be placed on an 1647 Objective-C method; it specifies that the method expects 1648 its <tt>self</tt> parameter to have a +1 retain count, which it will 1649 balance in some way.</p> 1650 1651 <pre> 1652 void <b>foo(__attribute__((ns_consumed))</b> NSString *string); 1653 1654 - (void) bar <b>__attribute__((ns_consumes_self))</b>; 1655 - (void) baz: (id) <b>__attribute__((ns_consumed))</b> x; 1656 </pre> 1657 1658 <p>Query for these features with <tt>__has_attribute(ns_consumed)</tt>, 1659 <tt>__has_attribute(ns_returns_retained)</tt>, etc.</p> 1660 1661 <!-- ======================================================================= --> 1662 <h2 id="dynamicanalyzerspecific">Dynamic Analysis-Specific Extensions</h2> 1663 <!-- ======================================================================= --> 1664 <h3 id="address_sanitizer">AddressSanitizer</h3> 1665 <p> Use <code>__has_feature(address_sanitizer)</code> 1666 to check if the code is being built with <a 1667 href="AddressSanitizer.html">AddressSanitizer</a>. 1668 </p> 1669 <p>Use <tt>__attribute__((no_address_safety_analysis))</tt> on a function 1670 declaration to specify that address safety instrumentation (e.g. 1671 AddressSanitizer) should not be applied to that function. 1672 </p> 1673 1674 <!-- ======================================================================= --> 1675 <h2 id="threadsafety">Thread-Safety Annotation Checking</h2> 1676 <!-- ======================================================================= --> 1677 1678 <p>Clang supports additional attributes for checking basic locking policies in 1679 multithreaded programs. 1680 Clang currently parses the following list of attributes, although 1681 <b>the implementation for these annotations is currently in development.</b> 1682 For more details, see the 1683 <a href="http://gcc.gnu.org/wiki/ThreadSafetyAnnotation">GCC implementation</a>. 1684 </p> 1685 1686 <h4 id="ts_noanal">no_thread_safety_analysis</h4> 1687 1688 <p>Use <tt>__attribute__((no_thread_safety_analysis))</tt> on a function 1689 declaration to specify that the thread safety analysis should not be run on that 1690 function. This attribute provides an escape hatch (e.g. for situations when it 1691 is difficult to annotate the locking policy). </p> 1692 1693 <h4 id="ts_lockable">lockable</h4> 1694 1695 <p>Use <tt>__attribute__((lockable))</tt> on a class definition to specify 1696 that it has a lockable type (e.g. a Mutex class). This annotation is primarily 1697 used to check consistency.</p> 1698 1699 <h4 id="ts_scopedlockable">scoped_lockable</h4> 1700 1701 <p>Use <tt>__attribute__((scoped_lockable))</tt> on a class definition to 1702 specify that it has a "scoped" lockable type. Objects of this type will acquire 1703 the lock upon construction and release it upon going out of scope. 1704 This annotation is primarily used to check 1705 consistency.</p> 1706 1707 <h4 id="ts_guardedvar">guarded_var</h4> 1708 1709 <p>Use <tt>__attribute__((guarded_var))</tt> on a variable declaration to 1710 specify that the variable must be accessed while holding some lock.</p> 1711 1712 <h4 id="ts_ptguardedvar">pt_guarded_var</h4> 1713 1714 <p>Use <tt>__attribute__((pt_guarded_var))</tt> on a pointer declaration to 1715 specify that the pointer must be dereferenced while holding some lock.</p> 1716 1717 <h4 id="ts_guardedby">guarded_by(l)</h4> 1718 1719 <p>Use <tt>__attribute__((guarded_by(l)))</tt> on a variable declaration to 1720 specify that the variable must be accessed while holding lock <tt>l</tt>.</p> 1721 1722 <h4 id="ts_ptguardedby">pt_guarded_by(l)</h4> 1723 1724 <p>Use <tt>__attribute__((pt_guarded_by(l)))</tt> on a pointer declaration to 1725 specify that the pointer must be dereferenced while holding lock <tt>l</tt>.</p> 1726 1727 <h4 id="ts_acquiredbefore">acquired_before(...)</h4> 1728 1729 <p>Use <tt>__attribute__((acquired_before(...)))</tt> on a declaration 1730 of a lockable variable to specify that the lock must be acquired before all 1731 attribute arguments. Arguments must be lockable type, and there must be at 1732 least one argument.</p> 1733 1734 <h4 id="ts_acquiredafter">acquired_after(...)</h4> 1735 1736 <p>Use <tt>__attribute__((acquired_after(...)))</tt> on a declaration 1737 of a lockable variable to specify that the lock must be acquired after all 1738 attribute arguments. Arguments must be lockable type, and there must be at 1739 least one argument.</p> 1740 1741 <h4 id="ts_elf">exclusive_lock_function(...)</h4> 1742 1743 <p>Use <tt>__attribute__((exclusive_lock_function(...)))</tt> on a function 1744 declaration to specify that the function acquires all listed locks 1745 exclusively. This attribute takes zero or more arguments: either of lockable 1746 type or integers indexing into function parameters of lockable type. If no 1747 arguments are given, the acquired lock is implicitly <tt>this</tt> of the 1748 enclosing object.</p> 1749 1750 <h4 id="ts_slf">shared_lock_function(...)</h4> 1751 1752 <p>Use <tt>__attribute__((shared_lock_function(...)))</tt> on a function 1753 declaration to specify that the function acquires all listed locks, although 1754 the locks may be shared (e.g. read locks). This attribute takes zero or more 1755 arguments: either of lockable type or integers indexing into function 1756 parameters of lockable type. If no arguments are given, the acquired lock is 1757 implicitly <tt>this</tt> of the enclosing object.</p> 1758 1759 <h4 id="ts_etf">exclusive_trylock_function(...)</h4> 1760 1761 <p>Use <tt>__attribute__((exclusive_lock_function(...)))</tt> on a function 1762 declaration to specify that the function will try (without blocking) to acquire 1763 all listed locks exclusively. This attribute takes one or more arguments. The 1764 first argument is an integer or boolean value specifying the return value of a 1765 successful lock acquisition. The remaining arugments are either of lockable type 1766 or integers indexing into function parameters of lockable type. If only one 1767 argument is given, the acquired lock is implicitly <tt>this</tt> of the 1768 enclosing object.</p> 1769 1770 <h4 id="ts_stf">shared_trylock_function(...)</h4> 1771 1772 <p>Use <tt>__attribute__((shared_lock_function(...)))</tt> on a function 1773 declaration to specify that the function will try (without blocking) to acquire 1774 all listed locks, although the locks may be shared (e.g. read locks). This 1775 attribute takes one or more arguments. The first argument is an integer or 1776 boolean value specifying the return value of a successful lock acquisition. The 1777 remaining arugments are either of lockable type or integers indexing into 1778 function parameters of lockable type. If only one argument is given, the 1779 acquired lock is implicitly <tt>this</tt> of the enclosing object.</p> 1780 1781 <h4 id="ts_uf">unlock_function(...)</h4> 1782 1783 <p>Use <tt>__attribute__((unlock_function(...)))</tt> on a function 1784 declaration to specify that the function release all listed locks. This 1785 attribute takes zero or more arguments: either of lockable type or integers 1786 indexing into function parameters of lockable type. If no arguments are given, 1787 the acquired lock is implicitly <tt>this</tt> of the enclosing object.</p> 1788 1789 <h4 id="ts_lr">lock_returned(l)</h4> 1790 1791 <p>Use <tt>__attribute__((lock_returned(l)))</tt> on a function 1792 declaration to specify that the function returns lock <tt>l</tt> (<tt>l</tt> 1793 must be of lockable type). This annotation is used to aid in resolving lock 1794 expressions.</p> 1795 1796 <h4 id="ts_le">locks_excluded(...)</h4> 1797 1798 <p>Use <tt>__attribute__((locks_excluded(...)))</tt> on a function declaration 1799 to specify that the function must not be called with the listed locks. Arguments 1800 must be lockable type, and there must be at least one argument.</p> 1801 1802 <h4 id="ts_elr">exclusive_locks_required(...)</h4> 1803 1804 <p>Use <tt>__attribute__((exclusive_locks_required(...)))</tt> on a function 1805 declaration to specify that the function must be called while holding the listed 1806 exclusive locks. Arguments must be lockable type, and there must be at 1807 least one argument.</p> 1808 1809 <h4 id="ts_slr">shared_locks_required(...)</h4> 1810 1811 <p>Use <tt>__attribute__((shared_locks_required(...)))</tt> on a function 1812 declaration to specify that the function must be called while holding the listed 1813 shared locks. Arguments must be lockable type, and there must be at 1814 least one argument.</p> 1815 1816 </div> 1817 </body> 1818 </html> 1819
