Clang 3.3 Release Notes¶
Written by the LLVM Team
Introduction¶
This document contains the release notes for the Clang C/C++/Objective-C frontend, part of the LLVM Compiler Infrastructure, release 3.3. Here we describe the status of Clang in some detail, including major improvements from the previous release and new feature work. For the general LLVM release notes, see the LLVM documentation. All LLVM releases may be downloaded from the LLVM releases web site.
For more information about Clang or LLVM, including information about the latest release, please check out the main please see the Clang Web Site or the LLVM Web Site.
Note that if you are reading this file from a Subversion checkout or the main Clang web page, this document applies to the next release, not the current one. To see the release notes for a specific release, please see the releases page.
What’s New in Clang 3.3?¶
Some of the major new features and improvements to Clang are listed here. Generic improvements to Clang as a whole or to its underlying infrastructure are described first, followed by language-specific sections with improvements to Clang’s support for those languages.
Major New Features¶
Extended Identifiers: Unicode Support and Universal Character Names¶
Clang 3.3 includes support for extended identifiers in C99 and C++. This feature allows identifiers to contain certain Unicode characters, as specified by the active language standard; these characters can be written directly in the source file using the UTF-8 encoding, or referred to using universal character names (\u00E0, \U000000E0).
C++ Language Changes in Clang¶
- Clang now has a feature-complete implementation of C++11, which can be
enabled with the -std=c++11
command-line flag. The following changes were made to Clang's C++11 implementation
for this release:
- Inheriting constructors are now supported.
- Thread-local variables with dynamic initialization and destruction are now supported using the thread_local keyword. This support requires a compatible C++ ABI library, such as g++4.8's runtime library.
- Support for the standard C++11 [[noreturn]] and [[carries_dependency]] attributes, and completed support for the alignas keyword. The [[carries_dependency]] currently has no runtime effect on any platform which Clang targets.
- Clang now correctly implements language linkage for functions and variables. This means that, for example, it is now possible to overload static functions declared in an extern "C" context. For backwards compatibility, an alias with the unmangled name is still emitted if it is the only one and has the used attribute.
- Experimental support is provided for some C++1y features. This support can be enabled with the -std=c++1y command-line flag, and includes binary literals (written 0b101010), aggregate initialization for classes with default initializers, and decltype(auto).
Internal API Changes¶
These are major API changes that have happened since the 3.2 release of Clang. If upgrading an external codebase that uses Clang as a library, this section should help get you past the largest hurdles of upgrading.
Value Casting¶
Certain type hierarchies (TypeLoc, CFGElement, ProgramPoint, and SVal) were misusing the llvm::cast machinery to perform undefined operations. Their APIs have been changed to use two member function templates that return values instead of pointers or references - “T castAs” and “Optional<T> getAs” (in the case of the TypeLoc hierarchy the latter is “T getAs” and you can use the boolean testability of a TypeLoc (or its ‘validity’) to verify that the cast succeeded). Essentially all previous ‘cast’ usage should be replaced with ‘castAs’ and ‘dyn_cast’ should be replaced with ‘getAs’. See r175462 for the first example of such a change along with many examples of how code was migrated to the new API.
Storage Class¶
For each variable and function Clang used to keep the storage class as written in the source, the linkage and a semantic storage class. This was a bit redundant and the semantic storage class has been removed. The method getStorageClass now returns what is written in the source code for that decl.
libclang¶
The clang_CXCursorSet_contains() function previously incorrectly returned 0 if it contained a CXCursor, contrary to what the documentation stated. This has been fixed so that the function returns a non-zero value if the set contains a cursor. This is API breaking change, but matches the intended original behavior. Moreover, this also fixes the issue of an invalid CXCursorSet appearing to contain any CXCursor.
Static Analyzer¶
The static analyzer (which contains additional code checking beyond compiler warnings) has improved significantly in both in the core analysis engine and also in the kinds of issues it can find.
Core Analysis Improvements¶
- Support for interprocedural reasoning about constructors and destructors.
- New false positive suppression mechanisms that reduced the number of false null pointer dereference warnings due to interprocedural analysis.
- Major performance enhancements to speed up interprocedural analysis
New Issues Found¶
- New memory error checks such as use-after-free with C++ ‘delete’.
- Detection of mismatched allocators and deallocators (e.g., using ‘new’ with ‘free()’, ‘malloc()’ with ‘delete’).
- Additional checks for misuses of Apple Foundation framework collection APIs.
Additional Information¶
A wide variety of additional information is available on the Clang web page. The web page contains versions of the API documentation which are up-to-date with the Subversion version of the source code. You can access versions of these documents specific to this release by going into the “clang/docs/” directory in the Clang tree.
If you have any questions or comments about Clang, please feel free to contact us via the mailing list.