diff options
Diffstat (limited to 'docs')
-rw-r--r-- | docs/InternalsManual.html | 57 | ||||
-rw-r--r-- | docs/LanguageExtensions.html | 22 | ||||
-rw-r--r-- | docs/UsersManual.html | 54 | ||||
-rw-r--r-- | docs/tools/clang.pod | 6 |
4 files changed, 103 insertions, 36 deletions
diff --git a/docs/InternalsManual.html b/docs/InternalsManual.html index 7aa26e0..6df26db 100644 --- a/docs/InternalsManual.html +++ b/docs/InternalsManual.html @@ -707,9 +707,10 @@ above, it would be the location of the "a" identifier.</li> last token replaced with the annotation token. In the example above, it would be the location of the "c" identifier.</li> -<li><b>void* "AnnotationValue"</b> - This contains an opaque object that the -parser gets from Sema through an Actions module, it is passed around and Sema -interprets it, based on the type of annotation token.</li> +<li><b>void* "AnnotationValue"</b> - This contains an opaque object +that the parser gets from Sema. The parser merely preserves the +information for Sema to later interpret based on the annotation token +kind.</li> <li><b>TokenKind "Kind"</b> - This indicates the kind of Annotation token this is. See below for the different valid kinds.</li> @@ -719,21 +720,29 @@ is. See below for the different valid kinds.</li> <ol> <li><b>tok::annot_typename</b>: This annotation token represents a -resolved typename token that is potentially qualified. The AnnotationValue -field contains a pointer returned by Action::getTypeName(). In the case of the -Sema actions module, this is a <tt>Decl*</tt> for the type.</li> - -<li><b>tok::annot_cxxscope</b>: This annotation token represents a C++ scope -specifier, such as "A::B::". This corresponds to the grammar productions "::" -and ":: [opt] nested-name-specifier". The AnnotationValue pointer is returned -by the Action::ActOnCXXGlobalScopeSpecifier and -Action::ActOnCXXNestedNameSpecifier callbacks. In the case of Sema, this is a -<tt>DeclContext*</tt>.</li> +resolved typename token that is potentially qualified. The +AnnotationValue field contains the <tt>QualType</tt> returned by +Sema::getTypeName(), possibly with source location information +attached.</li> + +<li><b>tok::annot_cxxscope</b>: This annotation token represents a C++ +scope specifier, such as "A::B::". This corresponds to the grammar +productions "::" and ":: [opt] nested-name-specifier". The +AnnotationValue pointer is a <tt>NestedNameSpecifier*</tt> returned by +the Sema::ActOnCXXGlobalScopeSpecifier and +Sema::ActOnCXXNestedNameSpecifier callbacks.</li> <li><b>tok::annot_template_id</b>: This annotation token represents a C++ template-id such as "foo<int, 4>", where "foo" is the name of a template. The AnnotationValue pointer is a pointer to a malloc'd -TemplateIdAnnotation object. Depending on the context, a parsed template-id that names a type might become a typename annotation token (if all we care about is the named type, e.g., because it occurs in a type specifier) or might remain a template-id token (if we want to retain more source location information or produce a new type, e.g., in a declaration of a class template specialization). template-id annotation tokens that refer to a type can be "upgraded" to typename annotation tokens by the parser.</li> +TemplateIdAnnotation object. Depending on the context, a parsed +template-id that names a type might become a typename annotation token +(if all we care about is the named type, e.g., because it occurs in a +type specifier) or might remain a template-id token (if we want to +retain more source location information or produce a new type, e.g., +in a declaration of a class template specialization). template-id +annotation tokens that refer to a type can be "upgraded" to typename +annotation tokens by the parser.</li> </ol> @@ -953,11 +962,12 @@ make sense to you :).</p> <h3 id="QualType">The QualType class</h3> <!-- ======================================================================= --> -<p>The QualType class is designed as a trivial value class that is small, -passed by-value and is efficient to query. The idea of QualType is that it -stores the type qualifiers (const, volatile, restrict) separately from the types -themselves: QualType is conceptually a pair of "Type*" and bits for the type -qualifiers.</p> +<p>The QualType class is designed as a trivial value class that is +small, passed by-value and is efficient to query. The idea of +QualType is that it stores the type qualifiers (const, volatile, +restrict, plus some extended qualifiers required by language +extensions) separately from the types themselves. QualType is +conceptually a pair of "Type*" and the bits for these type qualifiers.</p> <p>By storing the type qualifiers as bits in the conceptual pair, it is extremely efficient to get the set of qualifiers on a QualType (just return the @@ -972,10 +982,11 @@ both point to the same heap allocated "int" type). This reduces the heap size used to represent bits and also means we do not have to consider qualifiers when uniquing types (<a href="#Type">Type</a> does not even contain qualifiers).</p> -<p>In practice, on hosts where it is safe, the 3 type qualifiers are stored in -the low bit of the pointer to the Type object. This means that QualType is -exactly the same size as a pointer, and this works fine on any system where -malloc'd objects are at least 8 byte aligned.</p> +<p>In practice, the two most common type qualifiers (const and +restrict) are stored in the low bits of the pointer to the Type +object, together with a flag indicating whether extended qualifiers +are present (which must be heap-allocated). This means that QualType +is exactly the same size as a pointer.</p> <!-- ======================================================================= --> <h3 id="DeclarationName">Declaration names</h3> diff --git a/docs/LanguageExtensions.html b/docs/LanguageExtensions.html index 838b65f..75a4608 100644 --- a/docs/LanguageExtensions.html +++ b/docs/LanguageExtensions.html @@ -40,6 +40,7 @@ td { <li><a href="#cxx_static_assert">C++0x <tt>static_assert()</tt></a></li> <li><a href="#cxx_auto_type">C++0x type inference</a></li> <li><a href="#cxx_variadic_templates">C++0x variadic templates</a></li> + <li><a href="#cxx_inline_namespaces">C++0x inline namespaces</a></li> </ul> <li><a href="#blocks">Blocks</a></li> <li><a href="#overloading-in-c">Function Overloading in C</a></li> @@ -301,32 +302,34 @@ not yet implemented will be noted.</p> <h3 id="cxx_attributes">C++0x attributes</h3> <p>Use <tt>__has_feature(cxx_attributes)</tt> to determine if support for -attribute parsing with C++0x's square bracket notation is enabled. +attribute parsing with C++0x's square bracket notation is enabled.</p> <h3 id="cxx_deleted_functions">C++0x deleted functions</tt></h3> <p>Use <tt>__has_feature(cxx_deleted_functions)</tt> to determine if support for -deleted function definitions (with <tt>= delete</tt>) is enabled. +deleted function definitions (with <tt>= delete</tt>) is enabled.</p> <h3 id="cxx_concepts">C++ TR concepts</h3> <p>Use <tt>__has_feature(cxx_concepts)</tt> to determine if support for -concepts is enabled. clang does not currently implement this feature. +concepts is enabled. clang does not currently implement this feature.</p> <h3 id="cxx_lambdas">C++0x lambdas</h3> <p>Use <tt>__has_feature(cxx_lambdas)</tt> to determine if support for -lambdas is enabled. clang does not currently implement this feature. +lambdas is enabled. clang does not currently implement this feature.</p> <h3 id="cxx_nullptr">C++0x <tt>nullptr</tt></h3> <p>Use <tt>__has_feature(cxx_nullptr)</tt> to determine if support for -<tt>nullptr</tt> is enabled. clang does not yet fully implement this feature. +<tt>nullptr</tt> is enabled. clang does not yet fully implement this +feature.</p> <h3 id="cxx_rvalue_references">C++0x rvalue references</tt></h3> <p>Use <tt>__has_feature(cxx_rvalue_references)</tt> to determine if support for -rvalue references is enabled. clang does not yet fully implement this feature. +rvalue references is enabled. clang does not yet fully implement this +feature.</p> <h3 id="cxx_static_assert">C++0x <tt>static_assert()</tt></h3> @@ -339,12 +342,17 @@ compile-time assertions using <tt>static_assert</tt> is enabled.</p> is supported using the <tt>auto</tt> specifier. If this is disabled, <tt>auto</tt> will instead be a storage class specifier, as in C or C++98.</p> -<h3 id="cxx_variadic_templates">C++0x variadic templates</tt></h3> +<h3 id="cxx_variadic_templates">C++0x variadic templates</h3> <p>Use <tt>__has_feature(cxx_variadic_templates)</tt> to determine if support for templates taking any number of arguments with the ellipsis notation is enabled. clang does not yet fully implement this feature.</p> +<h3 id="cxx_inline_namespaces">C++0x inline namespaces</h3> + +<p>Use <tt>__has_feature(cxx_inline_namespaces)</tt> to determine if support for +inline namespaces is enabled.</p> + <!-- ======================================================================= --> <h2 id="blocks">Blocks</h2> <!-- ======================================================================= --> diff --git a/docs/UsersManual.html b/docs/UsersManual.html index 51e699f..7524161 100644 --- a/docs/UsersManual.html +++ b/docs/UsersManual.html @@ -39,6 +39,7 @@ td { <li><a href="#diagnostics_categories">Diagnostic Categories</a></li> <li><a href="#diagnostics_commandline">Controlling Diagnostics via Command Line Flags</a></li> <li><a href="#diagnostics_pragmas">Controlling Diagnostics via Pragmas</a></li> + <li><a href="#analyzer_diagnositics">Controlling Static Analyzer Diagnostics</a></li> </ul> <li><a href="#precompiledheaders">Precompiled Headers</a></li> <li><a href="#codegen">Controlling Code Generation</a></li> @@ -358,6 +359,18 @@ exprs.c:47:15:{47:8-47:14}{47:17-47:24}: error: invalid operands to binary expre <p>The {}'s are generated by -fdiagnostics-print-source-range-info.</p> </dd> +<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> +<dt id="opt_fdiagnostics-parseable-fixits"> +<b>-fdiagnostics-parseable-fixits</b>: +Print Fix-Its in a machine parseable form.</dt> +<dd><p>This option makes Clang print available Fix-Its in a machine parseable format at the end of diagnostics. The following example illustrates the format:</p> + +<pre> + fix-it:"t.cpp":{7:25-7:29}:"Gamma" +</pre> + +<p>The range printed is a half-open range, so in this example the characters at column 25 up to but not including column 29 on line 7 in t.cpp should be replaced with the string "Gamma". Either the range or the replacement string may be empty (representing strict insertions and strict erasures, respectively). Both the file name and the insertion string escape backslash (as "\\"), tabs (as "\t"), newlines (as "\n"), double quotes(as "\"") and non-printable characters (as octal "\xxx").</p> +</dd> </dl> @@ -579,6 +592,42 @@ GCC do not support the exact same set of warnings, so even when using GCC compatible #pragmas there is no guarantee that they will have identical behaviour on both compilers. </p> +<h4 id="analyzer_diagnositics">Controlling Static Analyzer Diagnostics</h4> + +<p>While not strictly part of the compiler, the diagnostics from Clang's <a +href="http://clang-analyzer.llvm.org">static analyzer</a> can also be influenced +by the user via changes to the source code. This can be done in two ways: + +<ul> + +<li id="analyzer_annotations"><b>Annotations</b>: The static analyzer recognizes various GCC-style +attributes (e.g., <tt>__attribute__((nonnull)))</tt>) that can either suppress +static analyzer warnings or teach the analyzer about code invariants which +enable it to find more bugs. While many of these attributes are standard GCC +attributes, additional ones have added to Clang to specifically support the +static analyzer. Detailed information on these annotations can be found in the +<a href="http://clang-analyzer.llvm.org/annotations.html">analyzer's +documentation</a>.</li> + +<li><b><tt>__clang_analyzer__</tt></b>: When the static analyzer is using Clang +to parse source files, it implicitly defines the preprocessor macro +<tt>__clang_analyzer__</tt>. While discouraged, code can use this macro to +selectively exclude code the analyzer examines. Here is an example: + +<pre> +#ifndef __clang_analyzer__ +// Code not to be analyzed +#endif +</pre> + +In general, this usage is discouraged. Instead, we prefer that users file bugs +against the analyzer when it flags false positives. There is also active +discussion of allowing users in the future to selectively silence specific +analyzer warnings (some which can already be done using <a +href="analyzer_annotations">annotations</a>).</li> + +</ul> + <!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = --> <h3 id="precompiledheaders">Precompiled Headers</h3> <!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = --> @@ -789,11 +838,6 @@ soon.</li> the uses described in the bug, this is likely to be implemented at some point, at least partially.</li> -<li>clang does not support #pragma align -(<a href="http://llvm.org/bugs/show_bug.cgi?id=3811">bug 3811</a>). This is a -relatively small feature, so it is likely to be implemented relatively -soon.</li> - <li>clang does not support code generation for local variables pinned to registers (<a href="http://llvm.org/bugs/show_bug.cgi?id=3933">bug 3933</a>). This is a relatively small feature, so it is likely to be implemented diff --git a/docs/tools/clang.pod b/docs/tools/clang.pod index 0c1ab57..032efcf 100644 --- a/docs/tools/clang.pod +++ b/docs/tools/clang.pod @@ -168,6 +168,10 @@ Enable support for Pascal-style strings with "\pfoo". Enable support for Microsoft extensions. +=item B<-fborland-extensions> + +Enable support for Borland extensions. + =item B<-fwritable-strings> Make all string literals default to writable. This disables uniquing of @@ -395,6 +399,7 @@ Show commands to run and use verbose output. B<-fshow-source-location> B<-fcaret-diagnostics> B<-fdiagnostics-fixit-info> +B<-fdiagnostics-parseable-fixits> B<-fdiagnostics-print-source-range-info> B<-fprint-source-range-info> B<-fdiagnostics-show-option> @@ -515,7 +520,6 @@ targets. =head1 BUGS -Clang currently does not have C++ support, and this manual page is incomplete. To report bugs, please visit L<http://llvm.org/bugs/>. Most bug reports should include preprocessed source files (use the B<-E> option) and the full output of the compiler, along with information to reproduce. |