diff --git a/.clang-format b/.clang-format new file mode 100644 index 000000000000..9b3aa8b7213b --- /dev/null +++ b/.clang-format @@ -0,0 +1 @@ +BasedOnStyle: LLVM diff --git a/CMakeLists.txt b/CMakeLists.txt index 5d05a4cdb552..8d02bf05f827 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -19,12 +19,14 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR ) endif() endif() - if( NOT EXISTS "${CLANG_PATH_TO_LLVM_BUILD}/bin/llvm-tblgen${CMAKE_EXECUTABLE_SUFFIX}" ) - # Looking for bin/Debug/llvm-tblgen is a complete hack. How can we get + if (EXISTS "${CLANG_PATH_TO_LLVM_BUILD}/bin/llvm-config${CMAKE_EXECUTABLE_SUFFIX}") + set (PATH_TO_LLVM_CONFIG "${CLANG_PATH_TO_LLVM_BUILD}/bin/llvm-config${CMAKE_EXECUTABLE_SUFFIX}") + elseif (EXISTS "${CLANG_PATH_TO_LLVM_BUILD}/bin/Debug/llvm-config${CMAKE_EXECUTABLE_SUFFIX}") + # Looking for bin/Debug/llvm-config is a complete hack. How can we get # around this? - if( NOT EXISTS "${CLANG_PATH_TO_LLVM_BUILD}/bin/Debug/llvm-tblgen${CMAKE_EXECUTABLE_SUFFIX}" ) - message(FATAL_ERROR "Please set CLANG_PATH_TO_LLVM_BUILD to a directory containing a LLVM build.") - endif() + set (PATH_TO_LLVM_CONFIG "${CLANG_PATH_TO_LLVM_BUILD}/bin/Debug/llvm-config${CMAKE_EXECUTABLE_SUFFIX}") + else() + message(FATAL_ERROR "Please set CLANG_PATH_TO_LLVM_BUILD to a directory containing a LLVM build.") endif() list(APPEND CMAKE_MODULE_PATH "${CLANG_PATH_TO_LLVM_BUILD}/share/llvm/cmake") @@ -32,6 +34,8 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR ) get_filename_component(PATH_TO_LLVM_BUILD ${CLANG_PATH_TO_LLVM_BUILD} ABSOLUTE) + option(LLVM_INSTALL_TOOLCHAIN_ONLY "Only include toolchain files in the 'install' target." OFF) + include(AddLLVM) include(TableGen) include("${CLANG_PATH_TO_LLVM_BUILD}/share/llvm/cmake/LLVMConfig.cmake") @@ -46,12 +50,8 @@ if( CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR ) include_directories("${PATH_TO_LLVM_BUILD}/include" "${LLVM_MAIN_INCLUDE_DIR}") link_directories("${PATH_TO_LLVM_BUILD}/lib") - if( EXISTS "${CLANG_PATH_TO_LLVM_BUILD}/bin/llvm-tblgen${CMAKE_EXECUTABLE_SUFFIX}" ) - set(LLVM_TABLEGEN_EXE "${PATH_TO_LLVM_BUILD}/bin/llvm-tblgen${CMAKE_EXECUTABLE_SUFFIX}") - else() - # FIXME: This is an utter hack. - set(LLVM_TABLEGEN_EXE "${PATH_TO_LLVM_BUILD}/bin/Debug/llvm-tblgen${CMAKE_EXECUTABLE_SUFFIX}") - endif() + exec_program("${PATH_TO_LLVM_CONFIG} --bindir" OUTPUT_VARIABLE LLVM_BINARY_DIR) + set(LLVM_TABLEGEN_EXE "${LLVM_BINARY_DIR}/llvm-tblgen${CMAKE_EXECUTABLE_SUFFIX}") # Define the default arguments to use with 'lit', and an option for the user # to override. @@ -90,6 +90,16 @@ if( CLANG_VENDOR ) add_definitions( -DCLANG_VENDOR="${CLANG_VENDOR} " ) endif() +set(CLANG_REPOSITORY_STRING "" CACHE STRING + "Vendor-specific text for showing the repository the source is taken from.") + +if(CLANG_REPOSITORY_STRING) + add_definitions(-DCLANG_REPOSITORY_STRING="${CLANG_REPOSITORY_STRING}") +endif() + +set(CLANG_VENDOR_UTI "org.llvm.clang" CACHE STRING + "Vendor-specific uti.") + set(CLANG_SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}) set(CLANG_BINARY_DIR ${CMAKE_CURRENT_BINARY_DIR}) @@ -151,7 +161,7 @@ if (LLVM_COMPILER_IS_GCC_COMPATIBLE) endif () if (APPLE) - set(CMAKE_MODULE_LINKER_FLAGS "-Wl,-flat_namespace -Wl,-undefined -Wl,suppress") + set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} -Wl,-flat_namespace -Wl,-undefined -Wl,suppress") endif () configure_file( @@ -189,6 +199,41 @@ function(clang_tablegen) endif() endfunction(clang_tablegen) +# FIXME: Generalize and move to llvm. +function(add_clang_symbol_exports target_name export_file) + # Makefile.rules contains special cases for different platforms. + # We restrict ourselves to Darwin for the time being. + if(${CMAKE_SYSTEM_NAME} MATCHES "Darwin") + add_custom_command(OUTPUT symbol.exports + COMMAND sed -e "s/^/_/" < ${export_file} > symbol.exports + DEPENDS ${export_file} + VERBATIM + COMMENT "Creating export file for ${target_name}") + add_custom_target(${target_name}_exports DEPENDS symbol.exports) + set_property(DIRECTORY APPEND + PROPERTY ADDITIONAL_MAKE_CLEAN_FILES symbol.exports) + + get_property(srcs TARGET ${target_name} PROPERTY SOURCES) + foreach(src ${srcs}) + get_filename_component(extension ${src} EXT) + if(extension STREQUAL ".cpp") + set(first_source_file ${src}) + break() + endif() + endforeach() + + # Force re-linking when the exports file changes. Actually, it + # forces recompilation of the source file. The LINK_DEPENDS target + # property only works for makefile-based generators. + set_property(SOURCE ${first_source_file} APPEND PROPERTY + OBJECT_DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/symbol.exports) + + set_property(TARGET ${target_name} APPEND_STRING PROPERTY + LINK_FLAGS " -Wl,-exported_symbols_list,${CMAKE_CURRENT_BINARY_DIR}/symbol.exports") + add_dependencies(${target_name} ${target_name}_exports) + endif() +endfunction(add_clang_symbol_exports) + macro(add_clang_library name) llvm_process_sources(srcs ${ARGN}) if(MSVC_IDE OR XCODE) @@ -228,11 +273,18 @@ macro(add_clang_library name) llvm_config( ${name} ${LLVM_LINK_COMPONENTS} ) target_link_libraries( ${name} ${LLVM_COMMON_LIBS} ) link_system_libs( ${name} ) + + if (SHARED_LIBRARY AND EXPORTED_SYMBOL_FILE) + add_clang_symbol_exports( ${name} ${EXPORTED_SYMBOL_FILE} ) + endif() + + if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY OR ${name} STREQUAL "libclang") + install(TARGETS ${name} + LIBRARY DESTINATION lib${LLVM_LIBDIR_SUFFIX} + ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX} + RUNTIME DESTINATION bin) + endif() - install(TARGETS ${name} - LIBRARY DESTINATION lib${LLVM_LIBDIR_SUFFIX} - ARCHIVE DESTINATION lib${LLVM_LIBDIR_SUFFIX} - RUNTIME DESTINATION bin) set_target_properties(${name} PROPERTIES FOLDER "Clang libraries") endmacro(add_clang_library) @@ -246,26 +298,58 @@ include_directories(BEFORE ${CMAKE_CURRENT_SOURCE_DIR}/include ) -install(DIRECTORY include/ - DESTINATION include - FILES_MATCHING - PATTERN "*.def" - PATTERN "*.h" - PATTERN "config.h" EXCLUDE - PATTERN ".svn" EXCLUDE - ) +if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY) + install(DIRECTORY include/ + DESTINATION include + FILES_MATCHING + PATTERN "*.def" + PATTERN "*.h" + PATTERN "config.h" EXCLUDE + PATTERN ".svn" EXCLUDE + ) -install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/include/ + install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/include/ + DESTINATION include + FILES_MATCHING + PATTERN "CMakeFiles" EXCLUDE + PATTERN "*.inc" + ) +endif() + +install(DIRECTORY include/clang-c DESTINATION include FILES_MATCHING - PATTERN "CMakeFiles" EXCLUDE - PATTERN "*.inc" + PATTERN "*.h" + PATTERN ".svn" EXCLUDE ) add_definitions( -D_GNU_SOURCE ) -# FIXME: They should be options. -add_definitions(-DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER) +option(CLANG_ENABLE_ARCMT "Build ARCMT." ON) +option(CLANG_ENABLE_REWRITER "Build rewriter." ON) +option(CLANG_ENABLE_STATIC_ANALYZER "Build static analyzer." ON) + +if (NOT CLANG_ENABLE_REWRITER AND CLANG_ENABLE_ARCMT) + message(FATAL_ERROR "Cannot disable rewriter while enabling ARCMT") +endif() + +if (NOT CLANG_ENABLE_REWRITER AND CLANG_ENABLE_STATIC_ANALYZER) + message(FATAL_ERROR "Cannot disable rewriter while enabling static analyzer") +endif() + +if (NOT CLANG_ENABLE_STATIC_ANALYZER AND CLANG_ENABLE_ARCMT) + message(FATAL_ERROR "Cannot disable static analyzer while enabling ARCMT") +endif() + +if(CLANG_ENABLE_ARCMT) + add_definitions(-DCLANG_ENABLE_ARCMT) +endif() +if(CLANG_ENABLE_REWRITER) + add_definitions(-DCLANG_ENABLE_REWRITER) +endif() +if(CLANG_ENABLE_STATIC_ANALYZER) + add_definitions(-DCLANG_ENABLE_STATIC_ANALYZER) +endif() # Clang version information set(CLANG_EXECUTABLE_VERSION @@ -290,13 +374,17 @@ option(CLANG_INCLUDE_TESTS "Generate build targets for the Clang unit tests." ${LLVM_INCLUDE_TESTS}) -# TODO: docs. -add_subdirectory(test) - if( CLANG_INCLUDE_TESTS ) + add_subdirectory(test) add_subdirectory(unittests) endif() +option(CLANG_INCLUDE_DOCS "Generate build targets for the Clang docs." + ${LLVM_INCLUDE_DOCS}) +if( CLANG_INCLUDE_DOCS ) + add_subdirectory(docs) +endif() + # Workaround for MSVS10 to avoid the Dialog Hell # FIXME: This could be removed with future version of CMake. if( CLANG_BUILT_STANDALONE AND MSVC_VERSION EQUAL 1600 ) @@ -309,3 +397,5 @@ endif() set(BUG_REPORT_URL "http://llvm.org/bugs/" CACHE STRING "Default URL where bug reports are to be submitted.") +set(CLANG_ORDER_FILE "" CACHE FILEPATH + "Order file to use when compiling clang in order to improve startup time.") diff --git a/CODE_OWNERS.TXT b/CODE_OWNERS.TXT index 13c0a9bde665..af5083184711 100644 --- a/CODE_OWNERS.TXT +++ b/CODE_OWNERS.TXT @@ -32,7 +32,7 @@ E: rjmccall@apple.com D: Clang LLVM IR generation N: Chad Rosier -E: mcrosier@apple.com +E: mcrosier@codeaurora.org D: MS-inline asm, and the compiler driver N: Richard Smith diff --git a/bindings/python/clang/cindex.py b/bindings/python/clang/cindex.py index 880a1502a4ba..c103c7078003 100644 --- a/bindings/python/clang/cindex.py +++ b/bindings/python/clang/cindex.py @@ -266,6 +266,29 @@ def __eq__(self, other): def __ne__(self, other): return not self.__eq__(other) + def __contains__(self, other): + """Useful to detect the Token/Lexer bug""" + if not isinstance(other, SourceLocation): + return False + if other.file is None and self.start.file is None: + pass + elif ( self.start.file.name != other.file.name or + other.file.name != self.end.file.name): + # same file name + return False + # same file, in between lines + if self.start.line < other.line < self.end.line: + return True + elif self.start.line == other.line: + # same file first line + if self.start.column <= other.column: + return True + elif other.line == self.end.line: + # same file last line + if other.column <= self.end.column: + return True + return False + def __repr__(self): return "" % (self.start, self.end) @@ -508,7 +531,7 @@ def name(self): @staticmethod def from_id(id): if id >= len(CursorKind._kinds) or CursorKind._kinds[id] is None: - raise ValueError,'Unknown cursor kind' + raise ValueError,'Unknown cursor kind %d' % id return CursorKind._kinds[id] @staticmethod @@ -721,10 +744,14 @@ def __repr__(self): # A reference to a labeled statement. CursorKind.LABEL_REF = CursorKind(48) -# A reference toa a set of overloaded functions or function templates +# A reference to a set of overloaded functions or function templates # that has not yet been resolved to a specific function or function template. CursorKind.OVERLOADED_DECL_REF = CursorKind(49) +# A reference to a variable that occurs in some non-expression +# context, e.g., a C++ lambda capture list. +CursorKind.VARIABLE_REF = CursorKind(50) + ### # Invalid/Error Kinds @@ -908,6 +935,26 @@ def __repr__(self): # pack. CursorKind.SIZE_OF_PACK_EXPR = CursorKind(143) +# Represents a C++ lambda expression that produces a local function +# object. +# +# \code +# void abssort(float *x, unsigned N) { +# std::sort(x, x + N, +# [](float a, float b) { +# return std::abs(a) < std::abs(b); +# }); +# } +# \endcode +CursorKind.LAMBDA_EXPR = CursorKind(144) + +# Objective-c Boolean Literal. +CursorKind.OBJ_BOOL_LITERAL_EXPR = CursorKind(145) + +# Represents the "self" expression in a ObjC method. +CursorKind.OBJ_SELF_EXPR = CursorKind(146) + + # A statement whose specific kind is not exposed via this interface. # # Unexposed statements have the same operations as any other kind of statement; @@ -999,6 +1046,9 @@ def __repr__(self): # Windows Structured Exception Handling's finally statement. CursorKind.SEH_FINALLY_STMT = CursorKind(228) +# A MS inline assembly statement extension. +CursorKind.MS_ASM_STMT = CursorKind(229) + # The null statement. CursorKind.NULL_STMT = CursorKind(230) @@ -1028,6 +1078,7 @@ def __repr__(self): CursorKind.CXX_OVERRIDE_ATTR = CursorKind(405) CursorKind.ANNOTATE_ATTR = CursorKind(406) CursorKind.ASM_LABEL_ATTR = CursorKind(407) +CursorKind.PACKED_ATTR = CursorKind(408) ### # Preprocessing @@ -1036,6 +1087,12 @@ def __repr__(self): CursorKind.MACRO_INSTANTIATION = CursorKind(502) CursorKind.INCLUSION_DIRECTIVE = CursorKind(503) +### +# Extra declaration + +# A module import declaration. +CursorKind.MODULE_IMPORT_DECL = CursorKind(600) + ### Cursors ### class Cursor(Structure): @@ -1282,6 +1339,16 @@ def referenced(self): return self._referenced + @property + def brief_comment(self): + """Returns the brief comment text associated with that Cursor""" + return conf.lib.clang_Cursor_getBriefCommentText(self) + + @property + def raw_comment(self): + """Returns the raw comment text associated with that Cursor""" + return conf.lib.clang_Cursor_getRawCommentText(self) + def get_arguments(self): """Return an iterator for accessing the arguments of this cursor.""" num_args = conf.lib.clang_Cursor_getNumArguments(self) @@ -1450,6 +1517,54 @@ def __repr__(self): TypeKind.FUNCTIONPROTO = TypeKind(111) TypeKind.CONSTANTARRAY = TypeKind(112) TypeKind.VECTOR = TypeKind(113) +TypeKind.INCOMPLETEARRAY = TypeKind(114) +TypeKind.VARIABLEARRAY = TypeKind(115) +TypeKind.DEPENDENTSIZEDARRAY = TypeKind(116) +TypeKind.MEMBERPOINTER = TypeKind(117) + +class RefQualifierKind(object): + """Describes a specific ref-qualifier of a type.""" + + # The unique kind objects, indexed by id. + _kinds = [] + _name_map = None + + def __init__(self, value): + if value >= len(RefQualifierKind._kinds): + num_kinds = value - len(RefQualifierKind._kinds) + 1 + RefQualifierKind._kinds += [None] * num_kinds + if RefQualifierKind._kinds[value] is not None: + raise ValueError, 'RefQualifierKind already loaded' + self.value = value + RefQualifierKind._kinds[value] = self + RefQualifierKind._name_map = None + + def from_param(self): + return self.value + + @property + def name(self): + """Get the enumeration name of this kind.""" + if self._name_map is None: + self._name_map = {} + for key, value in RefQualifierKind.__dict__.items(): + if isinstance(value, RefQualifierKind): + self._name_map[value] = key + return self._name_map[self] + + @staticmethod + def from_id(id): + if (id >= len(RefQualifierKind._kinds) or + RefQualifierKind._kinds[id] is None): + raise ValueError, 'Unknown type kind %d' % id + return RefQualifierKind._kinds[id] + + def __repr__(self): + return 'RefQualifierKind.%s' % (self.name,) + +RefQualifierKind.NONE = RefQualifierKind(0) +RefQualifierKind.LVALUE = RefQualifierKind(1) +RefQualifierKind.RVALUE = RefQualifierKind(2) class Type(Structure): """ @@ -1625,6 +1740,12 @@ def get_array_size(self): """ return conf.lib.clang_getArraySize(self) + def get_class_type(self): + """ + Retrieve the class type of the member pointer type. + """ + return conf.lib.clang_Type_getClassType(self) + def get_align(self): """ Retrieve the alignment of the record. @@ -1643,6 +1764,18 @@ def get_offset(self, fieldname): """ return conf.lib.clang_Type_getOffsetOf(self, c_char_p(fieldname)) + def get_ref_qualifier(self): + """ + Retrieve the ref-qualifier of the type. + """ + return RefQualifierKind.from_id( + conf.lib.clang_Type_getCXXRefQualifier(self)) + + @property + def spelling(self): + """Retrieve the spelling of this Type.""" + return conf.lib.clang_getTypeSpelling(self) + def __eq__(self, other): if type(other) != type(self): return False @@ -1918,7 +2051,7 @@ def __del__(self): def read(self, path): """Load a TranslationUnit from the given AST file.""" - return TranslationUnit.from_ast(path, self) + return TranslationUnit.from_ast_file(path, self) def parse(self, path, args=None, unsaved_files=None, options = 0): """Load the translation unit from the given source code file by running @@ -2590,6 +2723,10 @@ def cursor(self): [Index, c_char_p], c_object_p), + ("clang_CXXMethod_isPureVirtual", + [Cursor], + bool), + ("clang_CXXMethod_isStatic", [Cursor], bool), @@ -2973,6 +3110,11 @@ def cursor(self): _CXString, _CXString.from_result), + ("clang_getTypeSpelling", + [Type], + _CXString, + _CXString.from_result), + ("clang_hashCursor", [Cursor], c_uint), @@ -3077,17 +3219,36 @@ def cursor(self): [Cursor], bool), + ("clang_Cursor_getBriefCommentText", + [Cursor], + _CXString, + _CXString.from_result), + + ("clang_Cursor_getRawCommentText", + [Cursor], + _CXString, + _CXString.from_result), + ("clang_Type_getAlignOf", [Type], c_longlong), + ("clang_Type_getClassType", + [Type], + Type, + Type.from_result), + ("clang_Type_getOffsetOf", [Type, c_char_p], c_longlong), ("clang_Type_getSizeOf", [Type], - c_ulonglong), + c_longlong), + + ("clang_Type_getCXXRefQualifier", + [Type], + c_uint), ] class LibclangError(Exception): diff --git a/bindings/python/tests/cindex/test_comment.py b/bindings/python/tests/cindex/test_comment.py new file mode 100644 index 000000000000..d8f3129ac51e --- /dev/null +++ b/bindings/python/tests/cindex/test_comment.py @@ -0,0 +1,40 @@ +from clang.cindex import TranslationUnit +from tests.cindex.util import get_cursor + +def test_comment(): + files = [('fake.c', """ +/// Aaa. +int test1; + +/// Bbb. +/// x +void test2(void); + +void f() { + +} +""")] + # make a comment-aware TU + tu = TranslationUnit.from_source('fake.c', ['-std=c99'], unsaved_files=files, + options=TranslationUnit.PARSE_INCLUDE_BRIEF_COMMENTS_IN_CODE_COMPLETION) + test1 = get_cursor(tu, 'test1') + assert test1 is not None, "Could not find test1." + assert test1.type.is_pod() + raw = test1.raw_comment + brief = test1.brief_comment + assert raw == """/// Aaa.""" + assert brief == """Aaa.""" + + test2 = get_cursor(tu, 'test2') + raw = test2.raw_comment + brief = test2.brief_comment + assert raw == """/// Bbb.\n/// x""" + assert brief == """Bbb. x""" + + f = get_cursor(tu, 'f') + raw = f.raw_comment + brief = f.brief_comment + assert raw is None + assert brief is None + + diff --git a/bindings/python/tests/cindex/test_cursor_kind.py b/bindings/python/tests/cindex/test_cursor_kind.py index f8466e5e0d1d..8cabc512d4c5 100644 --- a/bindings/python/tests/cindex/test_cursor_kind.py +++ b/bindings/python/tests/cindex/test_cursor_kind.py @@ -4,8 +4,15 @@ def test_name(): assert CursorKind.UNEXPOSED_DECL.name is 'UNEXPOSED_DECL' def test_get_all_kinds(): - assert CursorKind.UNEXPOSED_DECL in CursorKind.get_all_kinds() - assert CursorKind.TRANSLATION_UNIT in CursorKind.get_all_kinds() + kinds = CursorKind.get_all_kinds() + assert CursorKind.UNEXPOSED_DECL in kinds + assert CursorKind.TRANSLATION_UNIT in kinds + assert CursorKind.VARIABLE_REF in kinds + assert CursorKind.LAMBDA_EXPR in kinds + assert CursorKind.OBJ_BOOL_LITERAL_EXPR in kinds + assert CursorKind.OBJ_SELF_EXPR in kinds + assert CursorKind.MS_ASM_STMT in kinds + assert CursorKind.MODULE_IMPORT_DECL in kinds def test_kind_groups(): """Check that every kind classifies to exactly one group.""" diff --git a/bindings/python/tests/cindex/test_type.py b/bindings/python/tests/cindex/test_type.py index 9bbed5aa940e..a02c06fe5a13 100644 --- a/bindings/python/tests/cindex/test_type.py +++ b/bindings/python/tests/cindex/test_type.py @@ -132,6 +132,22 @@ def test_equal(): assert a.type != None assert a.type != 'foo' +def test_type_spelling(): + """Ensure Type.spelling works.""" + tu = get_tu('int c[5]; int i[]; int x; int v[x];') + c = get_cursor(tu, 'c') + i = get_cursor(tu, 'i') + x = get_cursor(tu, 'x') + v = get_cursor(tu, 'v') + assert c is not None + assert i is not None + assert x is not None + assert v is not None + assert c.type.spelling == "int [5]" + assert i.type.spelling == "int []" + assert x.type.spelling == "int" + assert v.type.spelling == "int [x]" + def test_typekind_spelling(): """Ensure TypeKind.spelling works.""" tu = get_tu('int a;') @@ -237,12 +253,20 @@ def test_function_variadic(): def test_element_type(): """Ensure Type.element_type works.""" - tu = get_tu('int i[5];') + tu = get_tu('int c[5]; int i[]; int x; int v[x];') + c = get_cursor(tu, 'c') i = get_cursor(tu, 'i') + v = get_cursor(tu, 'v') + assert c is not None assert i is not None + assert v is not None - assert i.type.kind == TypeKind.CONSTANTARRAY + assert c.type.kind == TypeKind.CONSTANTARRAY + assert c.type.element_type.kind == TypeKind.INT + assert i.type.kind == TypeKind.INCOMPLETEARRAY assert i.type.element_type.kind == TypeKind.INT + assert v.type.kind == TypeKind.VARIABLEARRAY + assert v.type.element_type.kind == TypeKind.INT @raises(Exception) def test_invalid_element_type(): @@ -361,3 +385,13 @@ def test_offset(): assert teststruct.type.get_offset("bar") == bar +def test_decay(): + """Ensure decayed types are handled as the original type""" + + tu = get_tu("void foo(int a[]);") + foo = get_cursor(tu, 'foo') + a = foo.type.argument_types()[0] + + assert a.kind == TypeKind.INCOMPLETEARRAY + assert a.element_type.kind == TypeKind.INT + assert a.get_canonical().kind == TypeKind.INCOMPLETEARRAY diff --git a/bindings/xml/comment-xml-schema.rng b/bindings/xml/comment-xml-schema.rng index 22371dfed1e4..a8913a360b79 100644 --- a/bindings/xml/comment-xml-schema.rng +++ b/bindings/xml/comment-xml-schema.rng @@ -75,7 +75,6 @@ - @@ -91,6 +90,9 @@ + + + @@ -410,9 +412,14 @@ - - - + + + + + + + + @@ -435,6 +442,14 @@ + + + + + + + + diff --git a/docs/AddressSanitizer.rst b/docs/AddressSanitizer.rst index 89e864450009..5bc6d0b88b43 100644 --- a/docs/AddressSanitizer.rst +++ b/docs/AddressSanitizer.rst @@ -16,6 +16,7 @@ following types of bugs: * Use-after-free * Use-after-return (to some extent) * Double-free, invalid free +* Memory leaks (experimental) Typical slowdown introduced by AddressSanitizer is **2x**. @@ -114,8 +115,7 @@ function attribute (or a deprecated synonym `no_address_safety_analysis`) to disable instrumentation of a particular function. This attribute may not be supported by other compilers, so we suggest to use it together with -``__has_feature(address_sanitizer)``. Note: currently, this attribute will be -lost if the function is inlined. +``__has_feature(address_sanitizer)``. Initialization order checking ----------------------------- @@ -126,6 +126,42 @@ globals defined in another translation unit. To enable this check at runtime, you should set environment variable ``ASAN_OPTIONS=check_initialization_order=1``. +Blacklist +--------- + +AddressSanitizer supports ``src`` and ``fun`` entity types in +:doc:`SanitizerSpecialCaseList`, that can be used to suppress error reports +in the specified source files or functions. Additionally, AddressSanitizer +introduces ``global`` and ``type`` entity types that can be used to +suppress error reports for out-of-bound access to globals with certain +names and types (you may only specify class or struct types). + +You may use an ``init`` category to suppress reports about initialization-order +problems happening in certain source files or with certain global variables. + +.. code-block:: bash + + # Suppress error reports for code in a file or in a function: + src:bad_file.cpp + # Ignore all functions with names containing MyFooBar: + fun:*MyFooBar* + # Disable out-of-bound checks for global: + global:bad_array + # Disable out-of-bound checks for global instances of a given class ... + type:class.Namespace::BadClassName + # ... or a given struct. Use wildcard to deal with anonymous namespace. + type:struct.Namespace2::*::BadStructName + # Disable initialization-order checks for globals: + global:bad_init_global=init + type:*BadInitClassSubstring*=init + src:bad/init/files/*=init + +Memory leak detection +--------------------- + +For the experimental memory leak detector in AddressSanitizer, see +:doc:`LeakSanitizer`. + Supported Platforms =================== diff --git a/docs/CMakeLists.txt b/docs/CMakeLists.txt new file mode 100644 index 000000000000..8528c7af5840 --- /dev/null +++ b/docs/CMakeLists.txt @@ -0,0 +1,51 @@ + +if (DOXYGEN_FOUND) +if (LLVM_ENABLE_DOXYGEN) + set(abs_srcdir ${CMAKE_CURRENT_SOURCE_DIR}) + set(abs_builddir ${CMAKE_CURRENT_BINARY_DIR}) + + if (HAVE_DOT) + set(DOT ${LLVM_PATH_DOT}) + endif() + + if (LLVM_DOXYGEN_EXTERNAL_SEARCH) + set(enable_searchengine "YES") + set(searchengine_url "${LLVM_DOXYGEN_SEARCHENGINE_URL}") + set(enable_server_based_search "YES") + set(enable_external_search "YES") + set(extra_search_mappings "${LLVM_DOXYGEN_SEARCH_MAPPINGS}") + else() + set(enable_searchengine "NO") + set(searchengine_url "") + set(enable_server_based_search "NO") + set(enable_external_search "NO") + set(extra_search_mappings "") + endif() + + configure_file(${CMAKE_CURRENT_SOURCE_DIR}/doxygen.cfg.in + ${CMAKE_CURRENT_BINARY_DIR}/doxygen.cfg @ONLY) + + set(abs_top_srcdir) + set(abs_top_builddir) + set(DOT) + set(enable_searchengine) + set(searchengine_url) + set(enable_server_based_search) + set(enable_external_search) + set(extra_search_mappings) + + add_custom_target(doxygen-clang + COMMAND ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/doxygen.cfg + WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR} + COMMENT "Generating clang doxygen documentation." VERBATIM) + + if (LLVM_BUILD_DOCS) + add_dependencies(doxygen doxygen-clang) + endif() + + if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY) + install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/doxygen/html + DESTINATION docs/html) + endif() +endif() +endif() diff --git a/docs/ClangFormat.rst b/docs/ClangFormat.rst index 964fc84d7bca..bc6b8a2c41fa 100644 --- a/docs/ClangFormat.rst +++ b/docs/ClangFormat.rst @@ -15,26 +15,73 @@ to format C/C++/Obj-C code. .. code-block:: console - $ clang-format --help + $ clang-format -help OVERVIEW: A tool to format C/C++/Obj-C code. If no arguments are specified, it formats the code from standard input and writes the result to the standard output. - If is given, it reformats the file. If -i is specified together - with , the file is edited in-place. Otherwise, the result is - written to the standard output. + If s are given, it reformats the files. If -i is specified + together with s, the files are edited in-place. Otherwise, the + result is written to the standard output. - USAGE: clang-format [options] [] + USAGE: clang-format [options] [ ...] OPTIONS: - -fatal-assembler-warnings - Consider warnings as error - -help - Display available options (-help-hidden for more) - -i - Inplace edit , if specified. - -length= - Format a range of this length, -1 for end of file. - -offset= - Format a range starting at this file offset. - -stats - Enable statistics output from program - -style= - Coding style, currently supports: LLVM, Google, Chromium. - -version - Display the version of this program + + Clang-format options: + + -cursor= - The position of the cursor when invoking + clang-format from an editor integration + -dump-config - Dump configuration options to stdout and exit. + Can be used with -style option. + -i - Inplace edit s, if specified. + -length= - Format a range of this length (in bytes). + Multiple ranges can be formatted by specifying + several -offset and -length pairs. + When only a single -offset is specified without + -length, clang-format will format up to the end + of the file. + Can only be used with one input file. + -lines= - : - format a range of + lines (both 1-based). + Multiple ranges can be formatted by specifying + several -lines arguments. + Can't be used with -offset and -length. + Can only be used with one input file. + -offset= - Format a range starting at this byte offset. + Multiple ranges can be formatted by specifying + several -offset and -length pairs. + Can only be used with one input file. + -output-replacements-xml - Output replacements as XML. + -style= - Coding style, currently supports: + LLVM, Google, Chromium, Mozilla, WebKit. + Use -style=file to load style configuration from + .clang-format file located in one of the parent + directories of the source file (or current + directory for stdin). + Use -style="{key: value, ...}" to set specific + parameters, e.g.: + -style="{BasedOnStyle: llvm, IndentWidth: 8}" + + General options: + + -help - Display available options (-help-hidden for more) + -help-list - Display list of available options (-help-list-hidden for more) + -version - Display the version of this program + + +When the desired code formatting style is different from the available options, +the style can be customized using the ``-style="{key: value, ...}"`` option or +by putting your style configuration in the ``.clang-format`` or ``_clang-format`` +file in your project's directory and using ``clang-format -style=file``. + +An easy way to create the ``.clang-format`` file is: + +.. code-block:: console + + clang-format -style=llvm -dump-config > .clang-format + +Available style options are described in :doc:`ClangFormatStyleOptions`. Vim Integration @@ -96,6 +143,13 @@ menu item by renaming the script, and can assign the menu item a keyboard shortcut in the BBEdit preferences, under Menus & Shortcuts. +Visual Studio Integration +========================= + +Download the latest Visual Studio plugin from the `alpha build site +`_. The default key-binding is Ctrl-R,Ctrl-F. + + Script for patch reformatting ============================= @@ -106,18 +160,19 @@ a unified diff and reformats all contained lines with :program:`clang-format`. usage: clang-format-diff.py [-h] [-p P] [-style STYLE] - Reformat changed lines in diff + Reformat changed lines in diff. optional arguments: -h, --help show this help message and exit -p P strip the smallest prefix containing P slashes - -style STYLE formatting style to apply (LLVM, Google, Chromium) + -style STYLE formatting style to apply (LLVM, Google, Chromium, Mozilla, + WebKit) So to reformat all the lines in the latest :program:`git` commit, just do: .. code-block:: console - git diff -U0 HEAD^ | clang-format-diff.py + git diff -U0 HEAD^ | clang-format-diff.py -p1 The :option:`-U0` will create a diff without context lines (the script would format those as well). diff --git a/docs/ClangFormatStyleOptions.rst b/docs/ClangFormatStyleOptions.rst new file mode 100644 index 000000000000..d73801c7e73d --- /dev/null +++ b/docs/ClangFormatStyleOptions.rst @@ -0,0 +1,391 @@ +========================== +Clang-Format Style Options +========================== + +:doc:`ClangFormatStyleOptions` describes configurable formatting style options +supported by :doc:`LibFormat` and :doc:`ClangFormat`. + +When using :program:`clang-format` command line utility or +``clang::format::reformat(...)`` functions from code, one can either use one of +the predefined styles (LLVM, Google, Chromium, Mozilla, WebKit) or create a +custom style by configuring specific style options. + + +Configuring Style with clang-format +=================================== + +:program:`clang-format` supports two ways to provide custom style options: +directly specify style configuration in the ``-style=`` command line option or +use ``-style=file`` and put style configuration in the ``.clang-format`` or +``_clang-format`` file in the project directory. + +When using ``-style=file``, :program:`clang-format` for each input file will +try to find the ``.clang-format`` file located in the closest parent directory +of the input file. When the standard input is used, the search is started from +the current directory. + +The ``.clang-format`` file uses YAML format: + +.. code-block:: yaml + + key1: value1 + key2: value2 + # A comment. + ... + +An easy way to get a valid ``.clang-format`` file containing all configuration +options of a certain predefined style is: + +.. code-block:: console + + clang-format -style=llvm -dump-config > .clang-format + +When specifying configuration in the ``-style=`` option, the same configuration +is applied for all input files. The format of the configuration is: + +.. code-block:: console + + -style='{key1: value1, key2: value2, ...}' + + +Configuring Style in Code +========================= + +When using ``clang::format::reformat(...)`` functions, the format is specified +by supplying the `clang::format::FormatStyle +`_ +structure. + + +Configurable Format Style Options +================================= + +This section lists the supported style options. Value type is specified for +each option. For enumeration types possible values are specified both as a C++ +enumeration member (with a prefix, e.g. ``LS_Auto``), and as a value usable in +the configuration (without a prefix: ``Auto``). + + +**BasedOnStyle** (``string``) + The style used for all options not specifically set in the configuration. + + This option is supported only in the :program:`clang-format` configuration + (both within ``-style='{...}'`` and the ``.clang-format`` file). + + Possible values: + + * ``LLVM`` + A style complying with the `LLVM coding standards + `_ + * ``Google`` + A style complying with `Google's C++ style guide + `_ + * ``Chromium`` + A style complying with `Chromium's style guide + `_ + * ``Mozilla`` + A style complying with `Mozilla's style guide + `_ + * ``WebKit`` + A style complying with `WebKit's style guide + `_ + +.. START_FORMAT_STYLE_OPTIONS + +**AccessModifierOffset** (``int``) + The extra indent or outdent of access modifiers, e.g. ``public:``. + +**AlignEscapedNewlinesLeft** (``bool``) + If ``true``, aligns escaped newlines as far left as possible. + Otherwise puts them into the right-most column. + +**AlignTrailingComments** (``bool``) + If ``true``, aligns trailing comments. + +**AllowAllParametersOfDeclarationOnNextLine** (``bool``) + Allow putting all parameters of a function declaration onto + the next line even if ``BinPackParameters`` is ``false``. + +**AllowShortIfStatementsOnASingleLine** (``bool``) + If ``true``, ``if (a) return;`` can be put on a single + line. + +**AllowShortLoopsOnASingleLine** (``bool``) + If ``true``, ``while (true) continue;`` can be put on a + single line. + +**AlwaysBreakBeforeMultilineStrings** (``bool``) + If ``true``, always break before multiline string literals. + +**AlwaysBreakTemplateDeclarations** (``bool``) + If ``true``, always break after the ``template<...>`` of a + template declaration. + +**BinPackParameters** (``bool``) + If ``false``, a function call's or function definition's parameters + will either all be on the same line or will have one line each. + +**BreakBeforeBinaryOperators** (``bool``) + If ``true``, binary operators will be placed after line breaks. + +**BreakBeforeBraces** (``BraceBreakingStyle``) + The brace breaking style to use. + + Possible values: + + * ``BS_Attach`` (in configuration: ``Attach``) + Always attach braces to surrounding context. + * ``BS_Linux`` (in configuration: ``Linux``) + Like ``Attach``, but break before braces on function, namespace and + class definitions. + * ``BS_Stroustrup`` (in configuration: ``Stroustrup``) + Like ``Attach``, but break before function definitions. + * ``BS_Allman`` (in configuration: ``Allman``) + Always break before braces. + + +**BreakConstructorInitializersBeforeComma** (``bool``) + Always break constructor initializers before commas and align + the commas with the colon. + +**ColumnLimit** (``unsigned``) + The column limit. + + A column limit of ``0`` means that there is no column limit. In this case, + clang-format will respect the input's line breaking decisions within + statements. + +**ConstructorInitializerAllOnOneLineOrOnePerLine** (``bool``) + If the constructor initializers don't fit on a line, put each + initializer on its own line. + +**ConstructorInitializerIndentWidth** (``unsigned``) + The number of characters to use for indentation of constructor + initializer lists. + +**Cpp11BracedListStyle** (``bool``) + If ``true``, format braced lists as best suited for C++11 braced + lists. + + Important differences: + - No spaces inside the braced list. + - No line break before the closing brace. + - Indentation with the continuation indent, not with the block indent. + + Fundamentally, C++11 braced lists are formatted exactly like function + calls would be formatted in their place. If the braced list follows a name + (e.g. a type or variable name), clang-format formats as if the ``{}`` were + the parentheses of a function call with that name. If there is no name, + a zero-length name is assumed. + +**DerivePointerBinding** (``bool``) + If ``true``, analyze the formatted file for the most common binding. + +**ExperimentalAutoDetectBinPacking** (``bool``) + If ``true``, clang-format detects whether function calls and + definitions are formatted with one parameter per line. + + Each call can be bin-packed, one-per-line or inconclusive. If it is + inconclusive, e.g. completely on one line, but a decision needs to be + made, clang-format analyzes whether there are other bin-packed cases in + the input file and act accordingly. + + NOTE: This is an experimental flag, that might go away or be renamed. Do + not use this in config files, etc. Use at your own risk. + +**IndentCaseLabels** (``bool``) + Indent case labels one level from the switch statement. + + When ``false``, use the same indentation level as for the switch statement. + Switch statement body is always indented one level more than case labels. + +**IndentFunctionDeclarationAfterType** (``bool``) + If ``true``, indent when breaking function declarations which + are not also definitions after the type. + +**IndentWidth** (``unsigned``) + The number of columns to use for indentation. + +**MaxEmptyLinesToKeep** (``unsigned``) + The maximum number of consecutive empty lines to keep. + +**NamespaceIndentation** (``NamespaceIndentationKind``) + The indentation used for namespaces. + + Possible values: + + * ``NI_None`` (in configuration: ``None``) + Don't indent in namespaces. + * ``NI_Inner`` (in configuration: ``Inner``) + Indent only in inner namespaces (nested in other namespaces). + * ``NI_All`` (in configuration: ``All``) + Indent in all namespaces. + + +**ObjCSpaceBeforeProtocolList** (``bool``) + Add a space in front of an Objective-C protocol list, i.e. use + ``Foo `` instead of ``Foo``. + +**PenaltyBreakComment** (``unsigned``) + The penalty for each line break introduced inside a comment. + +**PenaltyBreakFirstLessLess** (``unsigned``) + The penalty for breaking before the first ``<<``. + +**PenaltyBreakString** (``unsigned``) + The penalty for each line break introduced inside a string literal. + +**PenaltyExcessCharacter** (``unsigned``) + The penalty for each character outside of the column limit. + +**PenaltyReturnTypeOnItsOwnLine** (``unsigned``) + Penalty for putting the return type of a function onto its own + line. + +**PointerBindsToType** (``bool``) + Set whether & and * bind to the type as opposed to the variable. + +**SpaceAfterControlStatementKeyword** (``bool``) + If ``true``, spaces will be inserted between 'for'/'if'/'while'/... + and '('. + +**SpaceBeforeAssignmentOperators** (``bool``) + If ``false``, spaces will be removed before assignment operators. + +**SpaceInEmptyParentheses** (``bool``) + If ``false``, spaces may be inserted into '()'. + +**SpacesBeforeTrailingComments** (``unsigned``) + The number of spaces to before trailing line comments. + +**SpacesInCStyleCastParentheses** (``bool``) + If ``false``, spaces may be inserted into C style casts. + +**SpacesInParentheses** (``bool``) + If ``true``, spaces will be inserted after every '(' and before + every ')'. + +**Standard** (``LanguageStandard``) + Format compatible with this standard, e.g. use + ``A >`` instead of ``A>`` for LS_Cpp03. + + Possible values: + + * ``LS_Cpp03`` (in configuration: ``Cpp03``) + Use C++03-compatible syntax. + * ``LS_Cpp11`` (in configuration: ``Cpp11``) + Use features of C++11 (e.g. ``A>`` instead of + ``A >``). + * ``LS_Auto`` (in configuration: ``Auto``) + Automatic detection based on the input. + + +**TabWidth** (``unsigned``) + The number of columns used for tab stops. + +**UseTab** (``UseTabStyle``) + The way to use tab characters in the resulting file. + + Possible values: + + * ``UT_Never`` (in configuration: ``Never``) + Never use tab. + * ``UT_ForIndentation`` (in configuration: ``ForIndentation``) + Use tabs only for indentation. + * ``UT_Always`` (in configuration: ``Always``) + Use tabs whenever we need to fill whitespace that spans at least from + one tab stop to the next one. + + +.. END_FORMAT_STYLE_OPTIONS + +Examples +======== + +A style similar to the `Linux Kernel style +`_: + +.. code-block:: yaml + + BasedOnStyle: LLVM + IndentWidth: 8 + UseTab: Always + BreakBeforeBraces: Linux + AllowShortIfStatementsOnASingleLine: false + IndentCaseLabels: false + +The result is (imagine that tabs are used for indentation here): + +.. code-block:: c++ + + void test() + { + switch (x) { + case 0: + case 1: + do_something(); + break; + case 2: + do_something_else(); + break; + default: + break; + } + if (condition) + do_something_completely_different(); + + if (x == y) { + q(); + } else if (x > y) { + w(); + } else { + r(); + } + } + +A style similar to the default Visual Studio formatting style: + +.. code-block:: yaml + + UseTab: Never + IndentWidth: 4 + BreakBeforeBraces: Allman + AllowShortIfStatementsOnASingleLine: false + IndentCaseLabels: false + ColumnLimit: 0 + +The result is: + +.. code-block:: c++ + + void test() + { + switch (suffix) + { + case 0: + case 1: + do_something(); + break; + case 2: + do_something_else(); + break; + default: + break; + } + if (condition) + do_somthing_completely_different(); + + if (x == y) + { + q(); + } + else if (x > y) + { + w(); + } + else + { + r(); + } + } + diff --git a/docs/ClangTools.rst b/docs/ClangTools.rst index 9312e6baf09a..f8a7c366dbaf 100644 --- a/docs/ClangTools.rst +++ b/docs/ClangTools.rst @@ -88,8 +88,8 @@ Clang-format is both a :doc:`library ` and a :doc:`stand-alone tool ` with the goal of automatically reformatting C++ sources files according to configurable style guides. To do so, clang-format uses Clang's ``Lexer`` to transform an input file into a token stream and then changes all -the whitespace around those tokens. The goal is for clang-format to both serve -both as a user tool (ideally with powerful IDE integrations) and part of other +the whitespace around those tokens. The goal is for clang-format to serve both +as a user tool (ideally with powerful IDE integrations) and as part of other refactoring tools, e.g. to do a reformatting of all the lines changed during a renaming. @@ -125,7 +125,7 @@ Ideas for new Tools ``foo`` is a standard container. We could also detect similar patterns for arrays. * ``make_shared`` / ``make_unique`` conversion. Part of this transformation -can be incorporated into the ``auto`` transformation. Will convert + can be incorporated into the ``auto`` transformation. Will convert .. code-block:: c++ diff --git a/docs/CrossCompilation.rst b/docs/CrossCompilation.rst new file mode 100644 index 000000000000..89f8777ac074 --- /dev/null +++ b/docs/CrossCompilation.rst @@ -0,0 +1,204 @@ +=================================================================== +Cross-compilation using Clang +=================================================================== + +Introduction +============ + +This document will guide you in choosing the right Clang options +for cross-compiling your code to a different architecture. It assumes you +already know how to compile the code in question for the host architecture, +and that you know how to choose additional include and library paths. + +However, this document is *not* a "how to" and won't help you setting your +build system or Makefiles, nor choosing the right CMake options, etc. +Also, it does not cover all the possible options, nor does it contain +specific examples for specific architectures. For a concrete example, the +`instructions for cross-compiling LLVM itself +`_ may be of interest. + +After reading this document, you should be familiar with the main issues +related to cross-compilation, and what main compiler options Clang provides +for performing cross-compilation. + +Cross compilation issues +======================== + +In GCC world, every host/target combination has its own set of binaries, +headers, libraries, etc. So, it's usually simple to download a package +with all files in, unzip to a directory and point the build system to +that compiler, that will know about its location and find all it needs to +when compiling your code. + +On the other hand, Clang/LLVM is natively a cross-compiler, meaning that +one set of programs can compile to all targets by setting the ``-target`` +option. That makes it a lot easier for programers wishing to compile to +different platforms and architectures, and for compiler developers that +only have to maintain one build system, and for OS distributions, that +need only one set of main packages. + +But, as is true to any cross-compiler, and given the complexity of +different architectures, OS's and options, it's not always easy finding +the headers, libraries or binutils to generate target specific code. +So you'll need special options to help Clang understand what target +you're compiling to, where your tools are, etc. + +Another problem is that compilers come with standard libraries only (like +``compiler-rt``, ``libcxx``, ``libgcc``, ``libm``, etc), so you'll have to +find and make available to the build system, every other library required +to build your software, that is specific to your target. It's not enough to +have your host's libraries installed. + +Finally, not all toolchains are the same, and consequently, not every Clang +option will work magically. Some options, like ``--sysroot`` (which +effectively changes the logical root for headers and libraries), assume +all your binaries and libraries are in the same directory, which may not +true when your cross-compiler was installed by the distribution's package +management. So, for each specific case, you may use more than one +option, and in most cases, you'll end up setting include paths (``-I``) and +library paths (``-L``) manually. + +To sum up, different toolchains can: + * be host/target specific or more flexible + * be in a single directory, or spread out across your system + * have different sets of libraries and headers by default + * need special options, which your build system won't be able to figure + out by itself + +General Cross-Compilation Options in Clang +========================================== + +Target Triple +------------- + +The basic option is to define the target architecture. For that, use +``-target ``. If you don't specify the target, CPU names won't +match (since Clang assumes the host triple), and the compilation will +go ahead, creating code for the host platform, which will break later +on when assembling or linking. + +The triple has the general format ``---``, where: + * ``arch`` = ``x86``, ``arm``, ``thumb``, ``mips``, etc. + * ``sub`` = for ex. on ARM: ``v5``, ``v6m``, ``v7a``, ``v7m``, etc. + * ``vendor`` = ``pc``, ``apple``, ``nvidia``, ``ibm``, etc. + * ``sys`` = ``none``, ``linux``, ``win32``, ``darwin``, ``cuda``, etc. + * ``abi`` = ``eabi``, ``gnu``, ``android``, ``macho``, ``elf``, etc. + +The sub-architecture options are available for their own architectures, +of course, so "x86v7a" doesn't make sense. The vendor needs to be +specified only if there's a relevant change, for instance between PC +and Apple. Most of the time it can be omitted (and Unknown) +will be assumed, which sets the defaults for the specified architecture. +The system name is generally the OS (linux, darwin), but could be special +like the bare-metal "none". + +When a parameter is not important, they can be omitted, or you can +choose ``unknown`` and the defaults will be used. If you choose a parameter +that Clang doesn't know, like ``blerg``, it'll ignore and assume +``unknown``, which is not always desired, so be careful. + +Finally, the ABI option is something that will pick default CPU/FPU, +define the specific behaviour of your code (PCS, extensions), +and also choose the correct library calls, etc. + +CPU, FPU, ABI +------------- + +Once your target is specified, it's time to pick the hardware you'll +be compiling to. For every architecture, a default set of CPU/FPU/ABI +will be chosen, so you'll almost always have to change it via flags. + +Typical flags include: + * ``-mcpu=``, like x86-64, swift, cortex-a15 + * ``-fpu=``, like SSE3, NEON, controlling the FP unit available + * ``-mfloat-abi=``, like soft, hard, controlling which registers + to use for floating-point + +The default is normally the common denominator, so that Clang doesn't +generate code that breaks. But that also means you won't get the best +code for your specific hardware, which may mean orders of magnitude +slower than you expect. + +For example, if your target is ``arm-none-eabi``, the default CPU will +be ``arm7tdmi`` using soft float, which is extremely slow on modern cores, +whereas if your triple is ``armv7a-none-eabi``, it'll be Cortex-A8 with +NEON, but still using soft-float, which is much better, but still not +great. + +Toolchain Options +----------------- + +There are three main options to control access to your cross-compiler: +``--sysroot``, ``-I``, and ``-L``. The two last ones are well known, +but they're particularly important for additional libraries +and headers that are specific to your target. + +There are two main ways to have a cross-compiler: + +#. When you have extracted your cross-compiler from a zip file into + a directory, you have to use ``--sysroot=``. The path is the + root directory where you have unpacked your file, and Clang will + look for the directories ``bin``, ``lib``, ``include`` in there. + + In this case, your setup should be pretty much done (if no + additional headers or libraries are needed), as Clang will find + all binaries it needs (assembler, linker, etc) in there. + +#. When you have installed via a package manager (modern Linux + distributions have cross-compiler packages available), make + sure the target triple you set is *also* the prefix of your + cross-compiler toolchain. + + In this case, Clang will find the other binaries (assembler, + linker), but not always where the target headers and libraries + are. People add system-specific clues to Clang often, but as + things change, it's more likely that it won't find than the + other way around. + + So, here, you'll be a lot safer if you specify the include/library + directories manually (via ``-I`` and ``-L``). + +Target-Specific Libraries +========================= + +All libraries that you compile as part of your build will be +cross-compiled to your target, and your build system will probably +find them in the right place. But all dependencies that are +normally checked against (like ``libxml`` or ``libz`` etc) will match +against the host platform, not the target. + +So, if the build system is not aware that you want to cross-compile +your code, it will get every dependency wrong, and your compilation +will fail during build time, not configure time. + +Also, finding the libraries for your target are not as easy +as for your host machine. There aren't many cross-libraries available +as packages to most OS's, so you'll have to either cross-compile them +from source, or download the package for your target platform, +extract the libraries and headers, put them in specific directories +and add ``-I`` and ``-L`` pointing to them. + +Also, some libraries have different dependencies on different targets, +so configuration tools to find dependencies in the host can get the +list wrong for the target platform. This means that the configuration +of your build can get things wrong when setting their own library +paths, and you'll have to augment it via additional flags (configure, +Make, CMake, etc). + +Multilibs +--------- + +When you want to cross-compile to more than one configuration, for +example hard-float-ARM and soft-float-ARM, you'll have to have multiple +copies of your libraries and (possibly) headers. + +Some Linux distributions have support for Multilib, which handle that +for you in an easier way, but if you're not careful and, for instance, +forget to specify ``-ccc-gcc-name armv7l-linux-gnueabihf-gcc`` (which +uses hard-float), Clang will pick the ``armv7l-linux-gnueabi-ld`` +(which uses soft-float) and linker errors will happen. + +The same is true if you're compiling for different ABIs, like ``gnueabi`` +and ``androideabi``, and might even link and run, but produce run-time +errors, which are much harder to track down and fix. + diff --git a/docs/DataFlowSanitizer.rst b/docs/DataFlowSanitizer.rst new file mode 100644 index 000000000000..e0e9d74efde9 --- /dev/null +++ b/docs/DataFlowSanitizer.rst @@ -0,0 +1,158 @@ +================= +DataFlowSanitizer +================= + +.. toctree:: + :hidden: + + DataFlowSanitizerDesign + +.. contents:: + :local: + +Introduction +============ + +DataFlowSanitizer is a generalised dynamic data flow analysis. + +Unlike other Sanitizer tools, this tool is not designed to detect a +specific class of bugs on its own. Instead, it provides a generic +dynamic data flow analysis framework to be used by clients to help +detect application-specific issues within their own code. + +Usage +===== + +With no program changes, applying DataFlowSanitizer to a program +will not alter its behavior. To use DataFlowSanitizer, the program +uses API functions to apply tags to data to cause it to be tracked, and to +check the tag of a specific data item. DataFlowSanitizer manages +the propagation of tags through the program according to its data flow. + +The APIs are defined in the header file ``sanitizer/dfsan_interface.h``. +For further information about each function, please refer to the header +file. + +ABI List +-------- + +DataFlowSanitizer uses a list of functions known as an ABI list to decide +whether a call to a specific function should use the operating system's native +ABI or whether it should use a variant of this ABI that also propagates labels +through function parameters and return values. The ABI list file also controls +how labels are propagated in the former case. DataFlowSanitizer comes with a +default ABI list which is intended to eventually cover the glibc library on +Linux but it may become necessary for users to extend the ABI list in cases +where a particular library or function cannot be instrumented (e.g. because +it is implemented in assembly or another language which DataFlowSanitizer does +not support) or a function is called from a library or function which cannot +be instrumented. + +DataFlowSanitizer's ABI list file is a :doc:`SanitizerSpecialCaseList`. +The pass treats every function in the ``uninstrumented`` category in the +ABI list file as conforming to the native ABI. Unless the ABI list contains +additional categories for those functions, a call to one of those functions +will produce a warning message, as the labelling behavior of the function +is unknown. The other supported categories are ``discard``, ``functional`` +and ``custom``. + +* ``discard`` -- To the extent that this function writes to (user-accessible) + memory, it also updates labels in shadow memory (this condition is trivially + satisfied for functions which do not write to user-accessible memory). Its + return value is unlabelled. +* ``functional`` -- Like ``discard``, except that the label of its return value + is the union of the label of its arguments. +* ``custom`` -- Instead of calling the function, a custom wrapper ``__dfsw_F`` + is called, where ``F`` is the name of the function. This function may wrap + the original function or provide its own implementation. This category is + generally used for uninstrumentable functions which write to user-accessible + memory or which have more complex label propagation behavior. The signature + of ``__dfsw_F`` is based on that of ``F`` with each argument having a + label of type ``dfsan_label`` appended to the argument list. If ``F`` + is of non-void return type a final argument of type ``dfsan_label *`` + is appended to which the custom function can store the label for the + return value. For example: + +.. code-block:: c++ + + void f(int x); + void __dfsw_f(int x, dfsan_label x_label); + + void *memcpy(void *dest, const void *src, size_t n); + void *__dfsw_memcpy(void *dest, const void *src, size_t n, + dfsan_label dest_label, dfsan_label src_label, + dfsan_label n_label, dfsan_label *ret_label); + +If a function defined in the translation unit being compiled belongs to the +``uninstrumented`` category, it will be compiled so as to conform to the +native ABI. Its arguments will be assumed to be unlabelled, but it will +propagate labels in shadow memory. + +For example: + +.. code-block:: none + + # main is called by the C runtime using the native ABI. + fun:main=uninstrumented + fun:main=discard + + # malloc only writes to its internal data structures, not user-accessible memory. + fun:malloc=uninstrumented + fun:malloc=discard + + # tolower is a pure function. + fun:tolower=uninstrumented + fun:tolower=functional + + # memcpy needs to copy the shadow from the source to the destination region. + # This is done in a custom function. + fun:memcpy=uninstrumented + fun:memcpy=custom + +Example +======= + +The following program demonstrates label propagation by checking that +the correct labels are propagated. + +.. code-block:: c++ + + #include + #include + + int main(void) { + int i = 1; + dfsan_label i_label = dfsan_create_label("i", 0); + dfsan_set_label(i_label, &i, sizeof(i)); + + int j = 2; + dfsan_label j_label = dfsan_create_label("j", 0); + dfsan_set_label(j_label, &j, sizeof(j)); + + int k = 3; + dfsan_label k_label = dfsan_create_label("k", 0); + dfsan_set_label(k_label, &k, sizeof(k)); + + dfsan_label ij_label = dfsan_get_label(i + j); + assert(dfsan_has_label(ij_label, i_label)); + assert(dfsan_has_label(ij_label, j_label)); + assert(!dfsan_has_label(ij_label, k_label)); + + dfsan_label ijk_label = dfsan_get_label(i + j + k); + assert(dfsan_has_label(ijk_label, i_label)); + assert(dfsan_has_label(ijk_label, j_label)); + assert(dfsan_has_label(ijk_label, k_label)); + + return 0; + } + +Current status +============== + +DataFlowSanitizer is a work in progress, currently under development for +x86\_64 Linux. + +Design +====== + +Please refer to the :doc:`design document`. diff --git a/docs/DataFlowSanitizerDesign.rst b/docs/DataFlowSanitizerDesign.rst new file mode 100644 index 000000000000..32db88bda269 --- /dev/null +++ b/docs/DataFlowSanitizerDesign.rst @@ -0,0 +1,220 @@ +DataFlowSanitizer Design Document +================================= + +This document sets out the design for DataFlowSanitizer, a general +dynamic data flow analysis. Unlike other Sanitizer tools, this tool is +not designed to detect a specific class of bugs on its own. Instead, +it provides a generic dynamic data flow analysis framework to be used +by clients to help detect application-specific issues within their +own code. + +DataFlowSanitizer is a program instrumentation which can associate +a number of taint labels with any data stored in any memory region +accessible by the program. The analysis is dynamic, which means that +it operates on a running program, and tracks how the labels propagate +through that program. The tool shall support a large (>100) number +of labels, such that programs which operate on large numbers of data +items may be analysed with each data item being tracked separately. + +Use Cases +--------- + +This instrumentation can be used as a tool to help monitor how data +flows from a program's inputs (sources) to its outputs (sinks). +This has applications from a privacy/security perspective in that +one can audit how a sensitive data item is used within a program and +ensure it isn't exiting the program anywhere it shouldn't be. + +Interface +--------- + +A number of functions are provided which will create taint labels, +attach labels to memory regions and extract the set of labels +associated with a specific memory region. These functions are declared +in the header file ``sanitizer/dfsan_interface.h``. + +.. code-block:: c + + /// Creates and returns a base label with the given description and user data. + dfsan_label dfsan_create_label(const char *desc, void *userdata); + + /// Sets the label for each address in [addr,addr+size) to \c label. + void dfsan_set_label(dfsan_label label, void *addr, size_t size); + + /// Sets the label for each address in [addr,addr+size) to the union of the + /// current label for that address and \c label. + void dfsan_add_label(dfsan_label label, void *addr, size_t size); + + /// Retrieves the label associated with the given data. + /// + /// The type of 'data' is arbitrary. The function accepts a value of any type, + /// which can be truncated or extended (implicitly or explicitly) as necessary. + /// The truncation/extension operations will preserve the label of the original + /// value. + dfsan_label dfsan_get_label(long data); + + /// Retrieves a pointer to the dfsan_label_info struct for the given label. + const struct dfsan_label_info *dfsan_get_label_info(dfsan_label label); + + /// Returns whether the given label label contains the label elem. + int dfsan_has_label(dfsan_label label, dfsan_label elem); + + /// If the given label label contains a label with the description desc, returns + /// that label, else returns 0. + dfsan_label dfsan_has_label_with_desc(dfsan_label label, const char *desc); + +Taint label representation +-------------------------- + +As stated above, the tool must track a large number of taint +labels. This poses an implementation challenge, as most multiple-label +tainting systems assign one label per bit to shadow storage, and +union taint labels using a bitwise or operation. This will not scale +to clients which use hundreds or thousands of taint labels, as the +label union operation becomes O(n) in the number of supported labels, +and data associated with it will quickly dominate the live variable +set, causing register spills and hampering performance. + +Instead, a low overhead approach is proposed which is best-case O(log\ +:sub:`2` n) during execution. The underlying assumption is that +the required space of label unions is sparse, which is a reasonable +assumption to make given that we are optimizing for the case where +applications mostly copy data from one place to another, without often +invoking the need for an actual union operation. The representation +of a taint label is a 16-bit integer, and new labels are allocated +sequentially from a pool. The label identifier 0 is special, and means +that the data item is unlabelled. + +When a label union operation is requested at a join point (any +arithmetic or logical operation with two or more operands, such as +addition), the code checks whether a union is required, whether the +same union has been requested before, and whether one union label +subsumes the other. If so, it returns the previously allocated union +label. If not, it allocates a new union label from the same pool used +for new labels. + +Specifically, the instrumentation pass will insert code like this +to decide the union label ``lu`` for a pair of labels ``l1`` +and ``l2``: + +.. code-block:: c + + if (l1 == l2) + lu = l1; + else + lu = __dfsan_union(l1, l2); + +The equality comparison is outlined, to provide an early exit in +the common cases where the program is processing unlabelled data, or +where the two data items have the same label. ``__dfsan_union`` is +a runtime library function which performs all other union computation. + +Further optimizations are possible, for example if ``l1`` is known +at compile time to be zero (e.g. it is derived from a constant), +``l2`` can be used for ``lu``, and vice versa. + +Memory layout and label management +---------------------------------- + +The following is the current memory layout for Linux/x86\_64: + ++---------------+---------------+--------------------+ +| Start | End | Use | ++===============+===============+====================+ +| 0x700000008000|0x800000000000 | application memory | ++---------------+---------------+--------------------+ +| 0x200200000000|0x700000008000 | unused | ++---------------+---------------+--------------------+ +| 0x200000000000|0x200200000000 | union table | ++---------------+---------------+--------------------+ +| 0x000000010000|0x200000000000 | shadow memory | ++---------------+---------------+--------------------+ +| 0x000000000000|0x000000010000 | reserved by kernel | ++---------------+---------------+--------------------+ + +Each byte of application memory corresponds to two bytes of shadow +memory, which are used to store its taint label. As for LLVM SSA +registers, we have not found it necessary to associate a label with +each byte or bit of data, as some other tools do. Instead, labels are +associated directly with registers. Loads will result in a union of +all shadow labels corresponding to bytes loaded (which most of the +time will be short circuited by the initial comparison) and stores will +result in a copy of the label to the shadow of all bytes stored to. + +Propagating labels through arguments +------------------------------------ + +In order to propagate labels through function arguments and return values, +DataFlowSanitizer changes the ABI of each function in the translation unit. +There are currently two supported ABIs: + +* Args -- Argument and return value labels are passed through additional + arguments and by modifying the return type. + +* TLS -- Argument and return value labels are passed through TLS variables + ``__dfsan_arg_tls`` and ``__dfsan_retval_tls``. + +The main advantage of the TLS ABI is that it is more tolerant of ABI mismatches +(TLS storage is not shared with any other form of storage, whereas extra +arguments may be stored in registers which under the native ABI are not used +for parameter passing and thus could contain arbitrary values). On the other +hand the args ABI is more efficient and allows ABI mismatches to be more easily +identified by checking for nonzero labels in nominally unlabelled programs. + +Implementing the ABI list +------------------------- + +The `ABI list `_ provides a list of functions +which conform to the native ABI, each of which is callable from an instrumented +program. This is implemented by replacing each reference to a native ABI +function with a reference to a function which uses the instrumented ABI. +Such functions are automatically-generated wrappers for the native functions. +For example, given the ABI list example provided in the user manual, the +following wrappers will be generated under the args ABI: + +.. code-block:: llvm + + define linkonce_odr { i8*, i16 } @"dfsw$malloc"(i64 %0, i16 %1) { + entry: + %2 = call i8* @malloc(i64 %0) + %3 = insertvalue { i8*, i16 } undef, i8* %2, 0 + %4 = insertvalue { i8*, i16 } %3, i16 0, 1 + ret { i8*, i16 } %4 + } + + define linkonce_odr { i32, i16 } @"dfsw$tolower"(i32 %0, i16 %1) { + entry: + %2 = call i32 @tolower(i32 %0) + %3 = insertvalue { i32, i16 } undef, i32 %2, 0 + %4 = insertvalue { i32, i16 } %3, i16 %1, 1 + ret { i32, i16 } %4 + } + + define linkonce_odr { i8*, i16 } @"dfsw$memcpy"(i8* %0, i8* %1, i64 %2, i16 %3, i16 %4, i16 %5) { + entry: + %labelreturn = alloca i16 + %6 = call i8* @__dfsw_memcpy(i8* %0, i8* %1, i64 %2, i16 %3, i16 %4, i16 %5, i16* %labelreturn) + %7 = load i16* %labelreturn + %8 = insertvalue { i8*, i16 } undef, i8* %6, 0 + %9 = insertvalue { i8*, i16 } %8, i16 %7, 1 + ret { i8*, i16 } %9 + } + +As an optimization, direct calls to native ABI functions will call the +native ABI function directly and the pass will compute the appropriate label +internally. This has the advantage of reducing the number of union operations +required when the return value label is known to be zero (i.e. ``discard`` +functions, or ``functional`` functions with known unlabelled arguments). + +Checking ABI Consistency +------------------------ + +DFSan changes the ABI of each function in the module. This makes it possible +for a function with the native ABI to be called with the instrumented ABI, +or vice versa, thus possibly invoking undefined behavior. A simple way +of statically detecting instances of this problem is to prepend the prefix +"dfs$" to the name of each instrumented-ABI function. + +This will not catch every such problem; in particular function pointers passed +across the instrumented-native barrier cannot be used on the other side. +These problems could potentially be caught dynamically. diff --git a/docs/InternalsManual.rst b/docs/InternalsManual.rst index 59dd2f98d6d6..6f5570263fc5 100644 --- a/docs/InternalsManual.rst +++ b/docs/InternalsManual.rst @@ -950,17 +950,13 @@ functions, Objective-C methods, C++ constructors, destructors, and operators ``DeclarationName`` is designed to efficiently represent any kind of name. Given a ``DeclarationName`` ``N``, ``N.getNameKind()`` will produce a value -that describes what kind of name ``N`` stores. There are 8 options (all of the -names are inside the ``DeclarationName`` class). +that describes what kind of name ``N`` stores. There are 10 options (all of +the names are inside the ``DeclarationName`` class). ``Identifier`` The name is a simple identifier. Use ``N.getAsIdentifierInfo()`` to retrieve the corresponding ``IdentifierInfo*`` pointing to the actual identifier. - Note that C++ overloaded operators (e.g., "``operator+``") are represented as - special kinds of identifiers. Use ``IdentifierInfo``'s - ``getOverloadedOperatorID`` function to determine whether an identifier is an - overloaded operator name. ``ObjCZeroArgSelector``, ``ObjCOneArgSelector``, ``ObjCMultiArgSelector`` @@ -999,6 +995,21 @@ names are inside the ``DeclarationName`` class). Use ``N.getCXXOverloadedOperator()`` to retrieve the overloaded operator (a value of type ``OverloadedOperatorKind``). +``CXXLiteralOperatorName`` + + The name is a C++11 user defined literal operator. User defined + Literal operators are named according to the suffix they define, + e.g., "``_foo``" for "``operator "" _foo``". Use + ``N.getCXXLiteralIdentifier()`` to retrieve the corresponding + ``IdentifierInfo*`` pointing to the identifier. + +``CXXUsingDirective`` + + The name is a C++ using directive. Using directives are not really + NamedDecls, in that they all have the same name, but they are + implemented as such in order to store them in DeclContext + effectively. + ``DeclarationName``\ s are cheap to create, copy, and compare. They require only a single pointer's worth of storage in the common cases (identifiers, zero- and one-argument Objective-C selectors) and use dense, uniqued storage diff --git a/docs/IntroductionToTheClangAST.rst b/docs/IntroductionToTheClangAST.rst index 81eb7ed0b9ef..600a6c884cb9 100644 --- a/docs/IntroductionToTheClangAST.rst +++ b/docs/IntroductionToTheClangAST.rst @@ -7,6 +7,12 @@ AST. It is targeted at developers who either want to contribute to Clang, or use tools that work based on Clang's AST, like the AST matchers. +.. raw:: html + +
+ +`Slides `_ + Introduction ============ @@ -27,9 +33,8 @@ Examining the AST ================= A good way to familarize yourself with the Clang AST is to actually look -at it on some simple example code. Clang has a builtin AST-dump modes, -which can be enabled with the flags ``-ast-dump`` and ``-ast-dump-xml``. Note -that ``-ast-dump-xml`` currently only works with debug builds of clang. +at it on some simple example code. Clang has a builtin AST-dump mode, +which can be enabled with the flag ``-ast-dump``. Let's look at a simple example AST: @@ -41,40 +46,26 @@ Let's look at a simple example AST: return result; } - # Clang by default is a frontend for many tools; -cc1 tells it to directly - # use the C++ compiler mode. -undef leaves out some internal declarations. - $ clang -cc1 -undef -ast-dump-xml test.cc + # Clang by default is a frontend for many tools; -Xclang is used to pass + # options directly to the C++ frontend. + $ clang -Xclang -ast-dump -fsyntax-only test.cc + TranslationUnitDecl 0x5aea0d0 <> ... cutting out internal declarations of clang ... - - - - - - - - - - - - - (CompoundStmt 0x48a5a38 - (DeclStmt 0x48a59c0 - 0x48a58c0 "int result = - (ParenExpr 0x48a59a0 'int' - (BinaryOperator 0x48a5978 'int' '/' - (ImplicitCastExpr 0x48a5960 'int' - (DeclRefExpr 0x48a5918 'int' lvalue ParmVar 0x4871d80 'x' 'int')) - (IntegerLiteral 0x48a5940 'int' 42)))") - (ReturnStmt 0x48a5a18 - (ImplicitCastExpr 0x48a5a00 'int' - (DeclRefExpr 0x48a59d8 'int' lvalue Var 0x48a58c0 'result' 'int')))) + `-FunctionDecl 0x5aeab50 f 'int (int)' + |-ParmVarDecl 0x5aeaa90 x 'int' + `-CompoundStmt 0x5aead88 + |-DeclStmt 0x5aead10 + | `-VarDecl 0x5aeac10 result 'int' + | `-ParenExpr 0x5aeacf0 'int' + | `-BinaryOperator 0x5aeacc8 'int' '/' + | |-ImplicitCastExpr 0x5aeacb0 'int' + | | `-DeclRefExpr 0x5aeac68 'int' lvalue ParmVar 0x5aeaa90 'x' 'int' + | `-IntegerLiteral 0x5aeac90 'int' 42 + `-ReturnStmt 0x5aead68 + `-ImplicitCastExpr 0x5aead50 'int' + `-DeclRefExpr 0x5aead28 'int' lvalue Var 0x5aeac10 'result' 'int' - - - - -In general, ``-ast-dump-xml`` dumps declarations in an XML-style format and -statements in an S-expression-style format. The toplevel declaration in +The toplevel declaration in a translation unit is always the `translation unit declaration `_. In this example, our first user written declaration is the `function diff --git a/docs/LanguageExtensions.rst b/docs/LanguageExtensions.rst index 324feafa98f0..7a4b31e7acc0 100644 --- a/docs/LanguageExtensions.rst +++ b/docs/LanguageExtensions.rst @@ -159,12 +159,16 @@ include paths, or 0 otherwise: # include "myinclude.h" #endif +To test for this feature, use ``#if defined(__has_include)``: + +.. code-block:: c++ + // To avoid problem with non-clang compilers not having this macro. - #if defined(__has_include) && __has_include("myinclude.h") + #if defined(__has_include) + #if __has_include("myinclude.h") # include "myinclude.h" #endif - -To test for this feature, use ``#if defined(__has_include)``. + #endif .. _langext-__has_include_next: @@ -185,9 +189,11 @@ or 0 otherwise: #endif // To avoid problem with non-clang compilers not having this macro. - #if defined(__has_include_next) && __has_include_next("myinclude.h") + #if defined(__has_include_next) + #if __has_include_next("myinclude.h") # include_next "myinclude.h" #endif + #endif Note that ``__has_include_next``, like the GNU extension ``#include_next`` directive, is intended for use in headers only, and will issue a warning if @@ -801,8 +807,7 @@ Use ``__has_feature(cxx_contextual_conversions)`` or ``__has_extension(cxx_contextual_conversions)`` to determine if the C++1y rules are used when performing an implicit conversion for an array bound in a *new-expression*, the operand of a *delete-expression*, an integral constant -expression, or a condition in a ``switch`` statement. Clang does not yet -support this feature. +expression, or a condition in a ``switch`` statement. C++1y decltype(auto) ^^^^^^^^^^^^^^^^^^^^ @@ -821,9 +826,9 @@ for default initializers in aggregate members is enabled. C++1y generalized lambda capture ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -Use ``__has_feature(cxx_generalized_capture)`` or -``__has_extension(cxx_generalized_capture`` to determine if support for -generalized lambda captures is enabled +Use ``__has_feature(cxx_init_capture)`` or +``__has_extension(cxx_init_capture)`` to determine if support for +lambda captures with explicit initializers is enabled (for instance, ``[n(0)] { return ++n; }``). Clang does not yet support this feature. @@ -843,7 +848,6 @@ Use ``__has_feature(cxx_relaxed_constexpr)`` or ``__has_extension(cxx_relaxed_constexpr)`` to determine if variable declarations, local variable modification, and control flow constructs are permitted in ``constexpr`` functions. -Clang's implementation of this feature is incomplete. C++1y return type deduction ^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -852,7 +856,6 @@ Use ``__has_feature(cxx_return_type_deduction)`` or ``__has_extension(cxx_return_type_deduction)`` to determine if support for return type deduction for functions (using ``auto`` as a return type) is enabled. -Clang's implementation of this feature is incomplete. C++1y runtime-sized arrays ^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -918,8 +921,8 @@ enabled. C11 ``_Thread_local`` ^^^^^^^^^^^^^^^^^^^^^ -Use ``__has_feature(c_thread_local)`` to determine if support for -``_Thread_local`` variables is enabled. +Use ``__has_feature(c_thread_local)`` or ``__has_extension(c_thread_local)`` +to determine if support for ``_Thread_local`` variables is enabled. Checks for Type Traits ====================== @@ -1173,8 +1176,52 @@ of this feature in version of clang being used. .. _langext-objc_method_family: -The ``objc_method_family`` attribute ------------------------------------- + +Objective-C requiring a call to ``super`` in an override +-------------------------------------------------------- + +Some Objective-C classes allow a subclass to override a particular method in a +parent class but expect that the overriding method also calls the overridden +method in the parent class. For these cases, we provide an attribute to +designate that a method requires a "call to ``super``" in the overriding +method in the subclass. + +**Usage**: ``__attribute__((objc_requires_super))``. This attribute can only +be placed at the end of a method declaration: + +.. code-block:: objc + + - (void)foo __attribute__((objc_requires_super)); + +This attribute can only be applied the method declarations within a class, and +not a protocol. Currently this attribute does not enforce any placement of +where the call occurs in the overriding method (such as in the case of +``-dealloc`` where the call must appear at the end). It checks only that it +exists. + +Note that on both OS X and iOS that the Foundation framework provides a +convenience macro ``NS_REQUIRES_SUPER`` that provides syntactic sugar for this +attribute: + +.. code-block:: objc + + - (void)foo NS_REQUIRES_SUPER; + +This macro is conditionally defined depending on the compiler's support for +this attribute. If the compiler does not support the attribute the macro +expands to nothing. + +Operationally, when a method has this annotation the compiler will warn if the +implementation of an override in a subclass does not call super. For example: + +.. code-block:: objc + + warning: method possibly missing a [super AnnotMeth] call + - (void) AnnotMeth{}; + ^ + +Objective-C Method Families +--------------------------- Many methods in Objective-C have conventional meanings determined by their selectors. It is sometimes useful to be able to mark a method as having a @@ -1253,6 +1300,21 @@ Query for these features with ``__has_attribute(ns_consumed)``, ``__has_attribute(ns_returns_retained)``, etc. +Objective-C++ ABI: protocol-qualifier mangling of parameters +------------------------------------------------------------ + +Starting with LLVM 3.4, Clang produces a new mangling for parameters whose +type is a qualified-``id`` (e.g., ``id``). This mangling allows such +parameters to be differentiated from those with the regular unqualified ``id`` +type. + +This was a non-backward compatible mangling change to the ABI. This change +allows proper overloading, and also prevents mangling conflicts with template +parameters of protocol-qualified type. + +Query the presence of this new mangling with +``__has_feature(objc_protocol_qualifier_mangling)``. + Function Overloading in C ========================= @@ -1411,7 +1473,9 @@ should only be used for timing small intervals. When not supported by the target, the return value is always zero. This builtin takes no arguments and produces an unsigned long long result. -Query for this feature with ``__has_builtin(__builtin_readcyclecounter)``. +Query for this feature with ``__has_builtin(__builtin_readcyclecounter)``. Note +that even if present, its use may depend on run-time privilege or other OS +controlled state. .. _langext-__builtin_shufflevector: @@ -1433,8 +1497,8 @@ for the implementation of various target-specific header files like .. code-block:: c++ - // Identity operation - return 4-element vector V1. - __builtin_shufflevector(V1, V1, 0, 1, 2, 3) + // identity operation - return 4-element vector v1. + __builtin_shufflevector(v1, v1, 0, 1, 2, 3) // "Splat" element 0 of V1 into a 4-element result. __builtin_shufflevector(V1, V1, 0, 0, 0, 0) @@ -1448,6 +1512,9 @@ for the implementation of various target-specific header files like // Concatenate every other element of 8-element vectors V1 and V2. __builtin_shufflevector(V1, V2, 0, 2, 4, 6, 8, 10, 12, 14) + // Shuffle v1 with some elements being undefined + __builtin_shufflevector(v1, v1, 3, -1, 1, -1) + **Description**: The first two arguments to ``__builtin_shufflevector`` are vectors that have @@ -1456,7 +1523,8 @@ specify the elements indices of the first two vectors that should be extracted and returned in a new vector. These element indices are numbered sequentially starting with the first vector, continuing into the second vector. Thus, if ``vec1`` is a 4-element vector, index 5 would refer to the second element of -``vec2``. +``vec2``. An index of -1 can be used to indicate that the corresponding element +in the returned vector is a don't care and can be optimized by the backend. The result of ``__builtin_shufflevector`` is a vector with the same element type as ``vec1``/``vec2`` but that has an element count equal to the number of @@ -1464,6 +1532,50 @@ indices specified. Query for this feature with ``__has_builtin(__builtin_shufflevector)``. +``__builtin_convertvector`` +--------------------------- + +``__builtin_convertvector`` is used to express generic vector +type-conversion operations. The input vector and the output vector +type must have the same number of elements. + +**Syntax**: + +.. code-block:: c++ + + __builtin_convertvector(src_vec, dst_vec_type) + +**Examples**: + +.. code-block:: c++ + + typedef double vector4double __attribute__((__vector_size__(32))); + typedef float vector4float __attribute__((__vector_size__(16))); + typedef short vector4short __attribute__((__vector_size__(8))); + vector4float vf; vector4short vs; + + // convert from a vector of 4 floats to a vector of 4 doubles. + __builtin_convertvector(vf, vector4double) + // equivalent to: + (vector4double) { (double) vf[0], (double) vf[1], (double) vf[2], (double) vf[3] } + + // convert from a vector of 4 shorts to a vector of 4 floats. + __builtin_convertvector(vs, vector4float) + // equivalent to: + (vector4float) { (float) vf[0], (float) vf[1], (float) vf[2], (float) vf[3] } + +**Description**: + +The first argument to ``__builtin_convertvector`` is a vector, and the second +argument is a vector type with the same number of elements as the first +argument. + +The result of ``__builtin_convertvector`` is a vector with the same element +type as the second argument, with a value defined in terms of the action of a +C-style cast applied to each element of the first argument. + +Query for this feature with ``__has_builtin(__builtin_convertvector)``. + ``__builtin_unreachable`` ------------------------- @@ -1526,6 +1638,22 @@ correct code by avoiding expensive loops around implementation details of ``__sync_lock_test_and_set()``. The ``__sync_swap()`` builtin is a full barrier. +``__builtin_addressof`` +----------------------- + +``__builtin_addressof`` performs the functionality of the built-in ``&`` +operator, ignoring any ``operator&`` overload. This is useful in constant +expressions in C++11, where there is no other way to take the address of an +object that overloads ``operator&``. + +**Example of use**: + +.. code-block:: c++ + + template constexpr T *addressof(T &value) { + return __builtin_addressof(value); + } + Multiprecision Arithmetic Builtins ---------------------------------- @@ -1554,15 +1682,60 @@ The complete list of builtins are: .. code-block:: c + unsigned char __builtin_addcb (unsigned char x, unsigned char y, unsigned char carryin, unsigned char *carryout); unsigned short __builtin_addcs (unsigned short x, unsigned short y, unsigned short carryin, unsigned short *carryout); unsigned __builtin_addc (unsigned x, unsigned y, unsigned carryin, unsigned *carryout); unsigned long __builtin_addcl (unsigned long x, unsigned long y, unsigned long carryin, unsigned long *carryout); unsigned long long __builtin_addcll(unsigned long long x, unsigned long long y, unsigned long long carryin, unsigned long long *carryout); + unsigned char __builtin_subcb (unsigned char x, unsigned char y, unsigned char carryin, unsigned char *carryout); unsigned short __builtin_subcs (unsigned short x, unsigned short y, unsigned short carryin, unsigned short *carryout); unsigned __builtin_subc (unsigned x, unsigned y, unsigned carryin, unsigned *carryout); unsigned long __builtin_subcl (unsigned long x, unsigned long y, unsigned long carryin, unsigned long *carryout); unsigned long long __builtin_subcll(unsigned long long x, unsigned long long y, unsigned long long carryin, unsigned long long *carryout); +Checked Arithmetic Builtins +--------------------------- + +Clang provides a set of builtins that implement checked arithmetic for security +critical applications in a manner that is fast and easily expressable in C. As +an example of their usage: + +.. code-block:: c + + errorcode_t security_critical_application(...) { + unsigned x, y, result; + ... + if (__builtin_umul_overflow(x, y, &result)) + return kErrorCodeHackers; + ... + use_multiply(result); + ... + } + +A complete enumeration of the builtins are: + +.. code-block:: c + + bool __builtin_uadd_overflow (unsigned x, unsigned y, unsigned *sum); + bool __builtin_uaddl_overflow (unsigned long x, unsigned long y, unsigned long *sum); + bool __builtin_uaddll_overflow(unsigned long long x, unsigned long long y, unsigned long long *sum); + bool __builtin_usub_overflow (unsigned x, unsigned y, unsigned *diff); + bool __builtin_usubl_overflow (unsigned long x, unsigned long y, unsigned long *diff); + bool __builtin_usubll_overflow(unsigned long long x, unsigned long long y, unsigned long long *diff); + bool __builtin_umul_overflow (unsigned x, unsigned y, unsigned *prod); + bool __builtin_umull_overflow (unsigned long x, unsigned long y, unsigned long *prod); + bool __builtin_umulll_overflow(unsigned long long x, unsigned long long y, unsigned long long *prod); + bool __builtin_sadd_overflow (int x, int y, int *sum); + bool __builtin_saddl_overflow (long x, long y, long *sum); + bool __builtin_saddll_overflow(long long x, long long y, long long *sum); + bool __builtin_ssub_overflow (int x, int y, int *diff); + bool __builtin_ssubl_overflow (long x, long y, long *diff); + bool __builtin_ssubll_overflow(long long x, long long y, long long *diff); + bool __builtin_smul_overflow (int x, int y, int *prod); + bool __builtin_smull_overflow (long x, long y, long *prod); + bool __builtin_smulll_overflow(long long x, long long y, long long *prod); + + .. _langext-__c11_atomic: __c11_atomic builtins @@ -1588,6 +1761,37 @@ C11's ```` header. These builtins provide the semantics of the * ``__c11_atomic_fetch_or`` * ``__c11_atomic_fetch_xor`` +Low-level ARM exclusive memory builtins +--------------------------------------- + +Clang provides overloaded builtins giving direct access to the three key ARM +instructions for implementing atomic operations. + +.. code-block:: c + + T __builtin_arm_ldrex(const volatile T *addr); + int __builtin_arm_strex(T val, volatile T *addr); + void __builtin_arm_clrex(void); + +The types ``T`` currently supported are: +* Integer types with width at most 64 bits. +* Floating-point types +* Pointer types. + +Note that the compiler does not guarantee it will not insert stores which clear +the exclusive monitor in between an ``ldrex`` and its paired ``strex``. In +practice this is only usually a risk when the extra store is on the same cache +line as the variable being modified and Clang will only insert stack stores on +its own, so it is best not to use these operations on variables with automatic +storage duration. + +Also, loads and stores may be implicit in code written between the ``ldrex`` and +``strex``. Clang will not necessarily mitigate the effects of these either, so +care should be exercised. + +For these reasons the higher level atomic primitives should be preferred where +possible. + Non-standard C++11 Attributes ============================= @@ -1649,7 +1853,7 @@ are accepted with the ``__attribute__((foo))`` syntax are also accepted as `_, `GCC variable attributes `_, and `GCC type attributes -`_. As with the GCC +`_). As with the GCC implementation, these attributes must appertain to the *declarator-id* in a declaration, which means they must go either at the start of the declaration or immediately after the name being declared. @@ -1698,6 +1902,48 @@ Which compiles to (on X86-32): movl %gs:(%eax), %eax ret +ARM Language Extensions +----------------------- + +Interrupt attribute +^^^^^^^^^^^^^^^^^^^ + +Clang supports the GNU style ``__attribute__((interrupt("TYPE")))`` attribute on +ARM targets. This attribute may be attached to a function definition and +instructs the backend to generate appropriate function entry/exit code so that +it can be used directly as an interrupt service routine. + + The parameter passed to the interrupt attribute is optional, but if +provided it must be a string literal with one of the following values: "IRQ", +"FIQ", "SWI", "ABORT", "UNDEF". + +The semantics are as follows: + +- If the function is AAPCS, Clang instructs the backend to realign the stack to + 8 bytes on entry. This is a general requirement of the AAPCS at public + interfaces, but may not hold when an exception is taken. Doing this allows + other AAPCS functions to be called. +- If the CPU is M-class this is all that needs to be done since the architecture + itself is designed in such a way that functions obeying the normal AAPCS ABI + constraints are valid exception handlers. +- If the CPU is not M-class, the prologue and epilogue are modified to save all + non-banked registers that are used, so that upon return the user-mode state + will not be corrupted. Note that to avoid unnecessary overhead, only + general-purpose (integer) registers are saved in this way. If VFP operations + are needed, that state must be saved manually. + + Specifically, interrupt kinds other than "FIQ" will save all core registers + except "lr" and "sp". "FIQ" interrupts will save r0-r7. +- If the CPU is not M-class, the return instruction is changed to one of the + canonical sequences permitted by the architecture for exception return. Where + possible the function itself will make the necessary "lr" adjustments so that + the "preferred return address" is selected. + + Unfortunately the compiler is unable to make this guarantee for an "UNDEF" + handler, where the offset from "lr" to the preferred return address depends on + the execution state of the code which generated the exception. In this case + a sequence equivalent to "movs pc, lr" will be used. + Extensions for Static Analysis ============================== @@ -1735,8 +1981,8 @@ with :doc:`ThreadSanitizer`. Use ``__attribute__((no_sanitize_thread))`` on a function declaration to specify that checks for data races on plain (non-atomic) memory accesses should not be inserted by ThreadSanitizer. -The function may still be instrumented by the tool -to avoid false positives in other places. +The function is still instrumented by the tool to avoid false positives and +provide meaningful stack traces. .. _langext-memory_sanitizer: @@ -1905,15 +2151,72 @@ to specify that the function must be called while holding the listed shared locks. Arguments must be lockable type, and there must be at least one argument. +Consumed Annotation Checking +============================ + +Clang supports additional attributes for checking basic resource management +properties, specifically for unique objects that have a single owning reference. +The following attributes are currently supported, although **the implementation +for these annotations is currently in development and are subject to change.** + +``consumable`` +-------------- + +Each class that uses any of the following annotations must first be marked +using the consumable attribute. Failure to do so will result in a warning. + +``set_typestate(new_state)`` +---------------------------- + +Annotate methods that transition an object into a new state with +``__attribute__((set_typestate(new_state)))``. The new new state must be +unconsumed, consumed, or unknown. + +``callable_when(...)`` +---------------------- + +Use ``__attribute__((callable_when(...)))`` to indicate what states a method +may be called in. Valid states are unconsumed, consumed, or unknown. Each +argument to this attribute must be a quoted string. E.g.: + +``__attribute__((callable_when("unconsumed", "unknown")))`` + +``tests_typestate(tested_state)`` +--------------------------------- + +Use ``__attribute__((tests_typestate(tested_state)))`` to indicate that a method +returns true if the object is in the specified state.. + +``param_typestate(expected_state)`` +----------------------------------- + +This attribute specifies expectations about function parameters. Calls to an +function with annotated parameters will issue a warning if the corresponding +argument isn't in the expected state. The attribute is also used to set the +initial state of the parameter when analyzing the function's body. + +``return_typestate(ret_state)`` +------------------------------- + +The ``return_typestate`` attribute can be applied to functions or parameters. +When applied to a function the attribute specifies the state of the returned +value. The function's body is checked to ensure that it always returns a value +in the specified state. On the caller side, values returned by the annotated +function are initialized to the given state. + +If the attribute is applied to a function parameter it modifies the state of +an argument after a call to the function returns. The function's body is +checked to ensure that the parameter is in the expected state before returning. + Type Safety Checking ==================== Clang supports additional attributes to enable checking type safety properties -that can't be enforced by C type system. Usecases include: +that can't be enforced by the C type system. Use cases include: * MPI library implementations, where these attributes enable checking that - buffer type matches the passed ``MPI_Datatype``; -* for HDF5 library there is a similar usecase as MPI; + the buffer type matches the passed ``MPI_Datatype``; +* for HDF5 library there is a similar use case to MPI; * checking types of variadic functions' arguments for functions like ``fcntl()`` and ``ioctl()``. @@ -1948,7 +2251,7 @@ accepts a type tag that determines the type of some other argument. applicable type tags. This attribute is primarily useful for checking arguments of variadic functions -(``pointer_with_type_tag`` can be used in most of non-variadic cases). +(``pointer_with_type_tag`` can be used in most non-variadic cases). For example: diff --git a/docs/LeakSanitizer.rst b/docs/LeakSanitizer.rst new file mode 100644 index 000000000000..b1071efd1aa2 --- /dev/null +++ b/docs/LeakSanitizer.rst @@ -0,0 +1,32 @@ +================ +LeakSanitizer +================ + +.. contents:: + :local: + +Introduction +============ + +LeakSanitizer is a run-time memory leak detector. It can be combined with +:doc:`AddressSanitizer` to get both memory error and leak detection. +LeakSanitizer does not introduce any additional slowdown when used in this mode. +The LeakSanitizer runtime can also be linked in separately to get leak detection +only, at a minimal performance cost. + +Current status +============== + +LeakSanitizer is experimental and supported only on x86\_64 Linux. + +The combined mode has been tested on fairly large software projects. The +stand-alone mode has received much less testing. + +There are plans to support LeakSanitizer in :doc:`MemorySanitizer` builds. + +More Information +================ + +`https://code.google.com/p/address-sanitizer/wiki/LeakSanitizer +`_ + diff --git a/docs/LibASTMatchersReference.html b/docs/LibASTMatchersReference.html index e80e4426f4b6..2c9b3aae0a89 100644 --- a/docs/LibASTMatchersReference.html +++ b/docs/LibASTMatchersReference.html @@ -57,6 +57,18 @@ find all matchers that can be used to match on Stmt nodes.

The exception to that rule are matchers that can match on any node. Those are marked with a * and are listed in the beginning of each category.

+

Note that the categorization of matchers is a great help when you combine +them into matcher expressions. You will usually want to form matcher expressions +that read like english sentences by alternating between node matchers and +narrowing or traversal matchers, like this: +

+recordDecl(hasDescendant(
+    ifStmt(hasTrueExpression(
+        expr(hasDescendant(
+            ifStmt()))))))
+
+

+

Node Matchers

@@ -73,10 +85,32 @@ and implicitly act as allOf matchers.

bind the matched node to the given string, to be later retrieved from the match callback.

+

It is important to remember that the arguments to node matchers are +predicates on the same node, just with additional information about the type. +This is often useful to make matcher expression more readable by inlining bind +calls into redundant node matchers inside another node matcher: +

+// This binds the CXXRecordDecl to "id", as the decl() matcher will stay on
+// the same node.
+recordDecl(decl().bind("id"), hasName("::MyClass"))
+
+

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - @@ -771,6 +887,14 @@ switchStmt() + + + + + + + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + - + - + + + + - + + + + + + + + + + + + + + + + + + - + - - - - - + - + - + - + - + - + - - + - + - - + - + - + + + + + + + + + + + + + @@ -2375,7 +2393,7 @@ FIXME: Overload to allow directly matching types? - + @@ -2438,7 +2456,7 @@ match Base. - + @@ -2471,17 +2494,38 @@ Example matches y in x(y) - - + + + + + @@ -2523,8 +2567,8 @@ classTemplateSpecializationDecl(hasTemplateArgument( - - + - + + + + + + + + + + + + + - - + @@ -2919,17 +3022,75 @@ FIXME: Unit test this matcher - - + + + + + + + + + @@ -2961,8 +3122,8 @@ memberExpr(member(hasName("first"))) - - + - + - + - + - - + - + - + - - + + + + + - + + + + + + + + + - - + + + + + + + + + @@ -3233,16 +3514,26 @@ QualType-matcher matches. - @@ -3264,6 +3555,30 @@ Example matches true (matcher = hasUnaryOperand(boolLiteral(equals(true)))) + + + + - - +
Return typeNameParameters
Matcher<CXXCtorInitializer>ctorInitializerMatcher<CXXCtorInitializer>...
Matches constructor initializers.
+
+Examples matches i(42).
+  class C {
+    C() : i(42) {}
+    int i;
+  };
+
Matcher<Decl>accessSpecDeclMatcher<AccessSpecDecl>...
Matches C++ access specifier declarations.
 
@@ -134,6 +168,17 @@ Examples matches X, C, and the friend declaration inside C;
 
Matcher<Decl>declaratorDeclMatcher<DeclaratorDecl>...
Matches declarator declarations (field, variable, function
+and non-type template parameter declarations).
+
+Given
+  class X { int y; };
+declaratorDecl()
+  matches int y.
+
Matcher<Decl>destructorDeclMatcher<CXXDestructorDecl>...
Matches explicit C++ destructor declarations.
 
@@ -175,6 +220,16 @@ fieldDecl()
 
Matcher<Decl>friendDeclMatcher<FriendDecl>...
Matches friend declarations.
+
+Given
+  class X { friend void foo(); };
+friendDecl()
+  matches 'friend void foo()'.
+
Matcher<Decl>functionDeclMatcher<FunctionDecl>...
Matches function declarations.
 
@@ -212,6 +267,27 @@ Example matches X, S, the anonymous union type, i, and U;
 
Matcher<Decl>namespaceDeclMatcher<NamespaceDecl>...
Matches a declaration of a namespace.
+
+Given
+  namespace {}
+  namespace test {}
+namespaceDecl()
+  matches "namespace {}" and "namespace test {}"
+
Matcher<Decl>parmVarDeclMatcher<ParmVarDecl>...
Matches parameter variable declarations.
+
+Given
+  void f(int x);
+parmVarDecl()
+  matches int x.
+
Matcher<Decl>recordDeclMatcher<CXXRecordDecl>...
Matches C++ class declarations.
 
@@ -221,6 +297,18 @@ Example matches X, Z
 
Matcher<Decl>unresolvedUsingValueDeclMatcher<UnresolvedUsingValueDecl>...
Matches unresolved using value declarations.
+
+Given
+  template<typename X>
+  class C : private X {
+    using X::x;
+  };
+unresolvedUsingValueDecl()
+  matches using X::x 
Matcher<Decl>usingDeclMatcher<UsingDecl>...
Matches using declarations.
 
@@ -341,6 +429,16 @@ Example matches x.y() and y()
 
Matcher<Stmt>caseStmtMatcher<CaseStmt>...
Matches case statements inside switch statements.
+
+Given
+  switch(a) { case 42: break; default: break; }
+caseStmt()
+  matches 'case 42: break;'.
+
Matcher<Stmt>castExprMatcher<CastExpr>...
Matches any cast nodes of Clang's AST.
 
@@ -460,6 +558,16 @@ Example matches the CXXDefaultArgExpr placeholder inserted for the
 
Matcher<Stmt>defaultStmtMatcher<DefaultStmt>...
Matches default statements inside switch statements.
+
+Given
+  switch(a) { case 42: break; default: break; }
+defaultStmt()
+  matches 'default: break;'.
+
Matcher<Stmt>deleteExprMatcher<CXXDeleteExpr>...
Matches delete expressions.
 
@@ -523,6 +631,15 @@ Example matches x()
 
Matcher<Stmt>floatLiteralMatcher<FloatingLiteral>...
Matches float literals of all sizes encodings, e.g.
+1.0, 1.0f, 1.0L and 1e10.
+
+Does not match implicit conversions such as
+  float a = 10;
+
Matcher<Stmt>forRangeStmtMatcher<CXXForRangeStmt>...
Matches range-based for statements.
 
@@ -591,11 +708,10 @@ initList()
 
 
 
Matcher<Stmt>integerLiteralMatcher<IntegerLiteral>...
Matches integer literals of all sizes encodings.
+
Matches integer literals of all sizes encodings, e.g.
+1, 1L, 0x1 and 1U.
 
-Not matching character-encoded integers such as L'a'.
-
-Example matches 1, 1L, 0x1, 1U
+Does not match character-encoded integers such as L'a'.
 
Matcher<Stmt>temporaryObjectExprMatcher<CXXTemporaryObjectExpr>...
Matches functional cast expressions having N != 1 arguments
+
+Example: Matches Foo(bar, bar)
+  Foo h = Foo(bar, bar);
+
Matcher<Stmt>thisExprMatcher<CXXThisExpr>...
Matches implicit and explicit this expressions.
 
@@ -820,6 +944,16 @@ Example matches !a
 
Matcher<Stmt>unresolvedConstructExprMatcher<CXXUnresolvedConstructExpr>...
Matches unresolved constructor call expressions.
+
+Example matches T(t) in return statement of f
+    (matcher = unresolvedConstructExpr())
+  template <typename T>
+  void f(const T& t) { return T(t); }
+
Matcher<Stmt>userDefinedLiteralMatcher<UserDefinedLiteral>...
Matches user defined literal operator call.
 
@@ -837,285 +971,11 @@ whileStmt()
 
Matcher<TypeLoc>arrayTypeLocMatcher<ArrayTypeLoc>...
Matches all kinds of arrays.
-
-Given
-  int a[] = { 2, 3 };
-  int b[4];
-  void f() { int c[a[0]]; }
-arrayType()
-  matches "int a[]", "int b[4]" and "int c[a[0]]";
-
Matcher<TypeLoc>atomicTypeLocMatcher<AtomicTypeLoc>...
Matches atomic types.
-
-Given
-  _Atomic(int) i;
-atomicType()
-  matches "_Atomic(int) i"
-
Matcher<TypeLoc>autoTypeLocMatcher<AutoTypeLoc>...
Matches types nodes representing C++11 auto types.
-
-Given:
-  auto n = 4;
-  int v[] = { 2, 3 }
-  for (auto i : v) { }
-autoType()
-  matches "auto n" and "auto i"
-
Matcher<TypeLoc>blockPointerTypeLocMatcher<BlockPointerTypeLoc>...
Matches block pointer types, i.e. types syntactically represented as
-"void (^)(int)".
-
-The pointee is always required to be a FunctionType.
-
Matcher<TypeLoc>builtinTypeLocMatcher<BuiltinTypeLoc>...
Matches builtin Types.
-
-Given
-  struct A {};
-  A a;
-  int b;
-  float c;
-  bool d;
-builtinType()
-  matches "int b", "float c" and "bool d"
-
Matcher<TypeLoc>complexTypeLocMatcher<ComplexTypeLoc>...
Matches C99 complex types.
-
-Given
-  _Complex float f;
-complexType()
-  matches "_Complex float f"
-
Matcher<TypeLoc>constantArrayTypeLocMatcher<ConstantArrayTypeLoc>...
Matches C arrays with a specified constant size.
-
-Given
-  void() {
-    int a[2];
-    int b[] = { 2, 3 };
-    int c[b[0]];
-  }
-constantArrayType()
-  matches "int a[2]"
-
Matcher<TypeLoc>dependentSizedArrayTypeLocMatcher<DependentSizedArrayTypeLoc>...
Matches C++ arrays whose size is a value-dependent expression.
-
-Given
-  template<typename T, int Size>
-  class array {
-    T data[Size];
-  };
-dependentSizedArrayType
-  matches "T data[Size]"
-
Matcher<TypeLoc>elaboratedTypeLocMatcher<ElaboratedTypeLoc>...
Matches types specified with an elaborated type keyword or with a
-qualified name.
-
-Given
-  namespace N {
-    namespace M {
-      class D {};
-    }
-  }
-  class C {};
-
-  class C c;
-  N::M::D d;
-
-elaboratedType() matches the type of the variable declarations of both
-c and d.
-
Matcher<TypeLoc>functionTypeLocMatcher<FunctionTypeLoc>...
Matches FunctionType nodes.
-
-Given
-  int (*f)(int);
-  void g();
-functionType()
-  matches "int (*f)(int)" and the type of "g".
-
Matcher<TypeLoc>incompleteArrayTypeLocMatcher<IncompleteArrayTypeLoc>...
Matches C arrays with unspecified size.
-
-Given
-  int a[] = { 2, 3 };
-  int b[42];
-  void f(int c[]) { int d[a[0]]; };
-incompleteArrayType()
-  matches "int a[]" and "int c[]"
-
Matcher<TypeLoc>lValueReferenceTypeLocMatcher<LValueReferenceTypeLoc>...
Matches lvalue reference types.
-
-Given:
-  int *a;
-  int &b = *a;
-  int &&c = 1;
-  auto &d = b;
-  auto &&e = c;
-  auto &&f = 2;
-  int g = 5;
-
-lValueReferenceType() matches the types of b, d, and e. e is
-matched since the type is deduced as int& by reference collapsing rules.
-
Matcher<TypeLoc>memberPointerTypeLocMatcher<MemberPointerTypeLoc>...
Matches member pointer types.
-Given
-  struct A { int i; }
-  A::* ptr = A::i;
-memberPointerType()
-  matches "A::* ptr"
-
Matcher<TypeLoc>parenTypeLocMatcher<ParenTypeLoc>...
Matches ParenType nodes.
-
-Given
-  int (*ptr_to_array)[4];
-  int *array_of_ptrs[4];
-
-varDecl(hasType(pointsTo(parenType()))) matches ptr_to_array but not
-array_of_ptrs.
-
Matcher<TypeLoc>pointerTypeLocMatcher<PointerTypeLoc>...
Matches pointer types.
-
-Given
-  int *a;
-  int &b = *a;
-  int c = 5;
-pointerType()
-  matches "int *a"
-
Matcher<TypeLoc>rValueReferenceTypeLocMatcher<RValueReferenceTypeLoc>...
Matches rvalue reference types.
-
-Given:
-  int *a;
-  int &b = *a;
-  int &&c = 1;
-  auto &d = b;
-  auto &&e = c;
-  auto &&f = 2;
-  int g = 5;
-
-rValueReferenceType() matches the types of c and f. e is not
-matched as it is deduced to int& by reference collapsing rules.
-
Matcher<TypeLoc>recordTypeLocMatcher<RecordTypeLoc>...
Matches record types (e.g. structs, classes).
-
-Given
-  class C {};
-  struct S {};
-
-  C c;
-  S s;
-
-recordType() matches the type of the variable declarations of both c
-and s.
-
Matcher<TypeLoc>referenceTypeLocMatcher<ReferenceTypeLoc>...
Matches both lvalue and rvalue reference types.
-
-Given
-  int *a;
-  int &b = *a;
-  int &&c = 1;
-  auto &d = b;
-  auto &&e = c;
-  auto &&f = 2;
-  int g = 5;
-
-referenceType() matches the types of b, c, d, e, and f.
-
Matcher<TypeLoc>templateSpecializationTypeLocMatcher<TemplateSpecializationTypeLoc>...
Matches template specialization types.
-
-Given
-  template <typename T>
-  class C { };
-
-  template class C<int>;  A
-  C<char> var;            B
-
-templateSpecializationType() matches the type of the explicit
-instantiation in A and the type of the variable declaration in B.
-
Matcher<TypeLoc>typeLocMatcher<TypeLoc>...
Matches TypeLocs in the clang AST.
 
Matcher<TypeLoc>typedefTypeLocMatcher<TypedefTypeLoc>...
Matches typedef types.
-
-Given
-  typedef int X;
-typedefType()
-  matches "typedef int X"
-
Matcher<TypeLoc>variableArrayTypeLocMatcher<VariableArrayTypeLoc>...
Matches C arrays with a specified size that is not an
-integer-constant-expression.
-
-Given
-  void f() {
-    int a[] = { 2, 3 }
-    int b[42];
-    int c[a[0]];
-variableArrayType()
-  matches "int c[a[0]]"
-
Matcher<Type>arrayTypeMatcher<ArrayType>...
Matches all kinds of arrays.
 
@@ -1381,6 +1241,16 @@ typedefType()
 
Matcher<Type>unaryTransformTypeMatcher<UnaryTransformType>...
Matches types nodes representing unary type transformations.
+
+Given:
+  typedef __underlying_type(T) type;
+unaryTransformType()
+  matches "__underlying_type(T)"
+
Matcher<Type>variableArrayTypeMatcher<VariableArrayType>...
Matches C arrays with a specified size that is not an
 integer-constant-expression.
@@ -1411,14 +1281,14 @@ which allow users to create more powerful match expressions.

Return typeNameParameters
Matcher<*>allOfMatcher<*> P1, Matcher<*> P2
Matcher<*>allOfMatcher<*>, ..., Matcher<*>
Matches if all given matchers match.
 
 Usable as: Any Matcher
 
Matcher<*>anyOfMatcher<*> P1, Matcher<*> P2
Matcher<*>anyOfMatcher<*>, ..., Matcher<*>
Matches if any of the given matchers matches.
 
 Usable as: Any Matcher
@@ -1472,6 +1342,16 @@ Usable as: Matcher<CXXConstructExpr>
argumentCountIsunsigned N
Checks that a call expression or a constructor call expression has
+a specific number of arguments (including absent default arguments).
+
+Example matches f(0, 0) (matcher = callExpr(argumentCountIs(2)))
+  void f(int x, int y);
+  f(0, 0);
+
Matcher<CXXConstructorDecl>isImplicit
Matches a constructor declaration that has been implicitly added
 by the compiler (eg. implicit defaultcopy constructors).
@@ -1479,7 +1359,7 @@ by the compiler (eg. implicit defaultcopy constructors).
 
 
 
Matcher<CXXCtorInitializer>isWritten
Matches a contructor initializer if it is explicitly written in
+
Matches a constructor initializer if it is explicitly written in
 code (as opposed to implicitly added by the compiler).
 
 Given
@@ -1513,6 +1393,19 @@ Usable as: Matcher<CXXMethodDecl>
isConst
Matches if the given method declaration is const.
+
+Given
+struct A {
+  void foo() const;
+  void bar();
+};
+
+methodDecl(isConst()) matches A::foo() but not A::bar()
+
Matcher<CXXMethodDecl>isOverride
Matches if the given method declaration overrides another method.
 
@@ -1665,6 +1558,29 @@ declCountIs(2)
 
Matcher<Decl>equalsBoundNodestd::string ID
Matches if a node equals a previously bound node.
+
+Matches a node if it equals the node previously bound to ID.
+
+Given
+  class X { int a; int b; };
+recordDecl(
+    has(fieldDecl(hasName("a"), hasType(type().bind("t")))),
+    has(fieldDecl(hasName("b"), hasType(type(equalsBoundNode("t"))))))
+  matches the class X, as a and b have the same type.
+
+Note that when multiple matches are involved via forEach* matchers,
+equalsBoundNodes acts as a filter.
+For example:
+compoundStmt(
+    forEachDescendant(varDecl().bind("d")),
+    forEachDescendant(declRefExpr(to(decl(equalsBoundNode("d"))))))
+will trigger a match for each combination of variable declaration
+and reference to that variable declaration within a compound statement.
+
Matcher<Decl>equalsNodeDecl* Other
Matches if a node equals another node.
 
@@ -1868,6 +1784,29 @@ callExpr(on(hasType(asString("class Y *"))))
 
Matcher<QualType>equalsBoundNodestd::string ID
Matches if a node equals a previously bound node.
+
+Matches a node if it equals the node previously bound to ID.
+
+Given
+  class X { int a; int b; };
+recordDecl(
+    has(fieldDecl(hasName("a"), hasType(type().bind("t")))),
+    has(fieldDecl(hasName("b"), hasType(type(equalsBoundNode("t"))))))
+  matches the class X, as a and b have the same type.
+
+Note that when multiple matches are involved via forEach* matchers,
+equalsBoundNodes acts as a filter.
+For example:
+compoundStmt(
+    forEachDescendant(varDecl().bind("d")),
+    forEachDescendant(declRefExpr(to(decl(equalsBoundNode("d"))))))
+will trigger a match for each combination of variable declaration
+and reference to that variable declaration within a compound statement.
+
Matcher<QualType>hasLocalQualifiers
Matches QualType nodes that have local CV-qualifiers attached to
 the node, not hidden within a typedef.
@@ -1912,6 +1851,29 @@ matches "a(int)", "b(long)", but not "c(double)".
 
Matcher<Stmt>equalsBoundNodestd::string ID
Matches if a node equals a previously bound node.
+
+Matches a node if it equals the node previously bound to ID.
+
+Given
+  class X { int a; int b; };
+recordDecl(
+    has(fieldDecl(hasName("a"), hasType(type().bind("t")))),
+    has(fieldDecl(hasName("b"), hasType(type(equalsBoundNode("t"))))))
+  matches the class X, as a and b have the same type.
+
+Note that when multiple matches are involved via forEach* matchers,
+equalsBoundNodes acts as a filter.
+For example:
+compoundStmt(
+    forEachDescendant(varDecl().bind("d")),
+    forEachDescendant(declRefExpr(to(decl(equalsBoundNode("d"))))))
+will trigger a match for each combination of variable declaration
+and reference to that variable declaration within a compound statement.
+
Matcher<Stmt>equalsNodeStmt* Other
Matches if a node equals another node.
 
@@ -1935,6 +1897,29 @@ Usable as: Matcher<Type>
equalsBoundNodestd::string ID
Matches if a node equals a previously bound node.
+
+Matches a node if it equals the node previously bound to ID.
+
+Given
+  class X { int a; int b; };
+recordDecl(
+    has(fieldDecl(hasName("a"), hasType(type().bind("t")))),
+    has(fieldDecl(hasName("b"), hasType(type(equalsBoundNode("t"))))))
+  matches the class X, as a and b have the same type.
+
+Note that when multiple matches are involved via forEach* matchers,
+equalsBoundNodes acts as a filter.
+For example:
+compoundStmt(
+    forEachDescendant(varDecl().bind("d")),
+    forEachDescendant(declRefExpr(to(decl(equalsBoundNode("d"))))))
+will trigger a match for each combination of variable declaration
+and reference to that variable declaration within a compound statement.
+
Matcher<UnaryExprOrTypeTraitExpr>ofKindUnaryExprOrTypeTrait Kind
Matches unary expressions of a certain kind.
 
@@ -2022,7 +2007,7 @@ match expressions.

Return typeNameParameters
Matcher<*>eachOfMatcher<*> P1, Matcher<*> P2
Matcher<*>eachOfMatcher<*>, ..., Matcher<*>
Matches if any of the given matchers matches.
 
 Unlike anyOf, eachOf will generate a match result for each
@@ -2041,22 +2026,7 @@ Usable as: Any Matcher
 
Matcher<*>findAllMatcher<T> Matcher
Matches if the node or any descendant matches.
-
-Generates results for each match.
-
-For example, in:
-  class A { class B {}; class C {}; };
-The matcher:
-  recordDecl(hasName("::A"), findAll(recordDecl(isDefinition()).bind("m")))
-will generate results for A, B and C.
-
-Usable as: Any Matcher
-
Matcher<*>forEachMatcher<ChildT> ChildMatcher
Matcher<*>forEachMatcher<*>
Matches AST nodes that have child AST nodes that match the
 provided matcher.
 
@@ -2074,7 +2044,7 @@ Usable as: Any Matcher
 
Matcher<*>forEachDescendantMatcher<DescendantT> DescendantMatcher
Matcher<*>forEachDescendantMatcher<*>
Matches AST nodes that have descendant AST nodes that match the
 provided matcher.
 
@@ -2098,7 +2068,7 @@ Usable as: Any Matcher
 
Matcher<*>hasMatcher<ChildT> ChildMatcher
Matcher<*>hasMatcher<*>
Matches AST nodes that have child AST nodes that match the
 provided matcher.
 
@@ -2113,7 +2083,7 @@ Usable as: Any Matcher
 
Matcher<*>hasAncestorMatcher<AncestorT> AncestorMatcher
Matcher<*>hasAncestorMatcher<*>
Matches AST nodes that have an ancestor that matches the provided
 matcher.
 
@@ -2126,7 +2096,7 @@ Usable as: Any Matcher
 
Matcher<*>hasDescendantMatcher<DescendantT> DescendantMatcher
Matcher<*>hasDescendantMatcher<*>
Matches AST nodes that have descendant AST nodes that match the
 provided matcher.
 
@@ -2142,7 +2112,7 @@ Usable as: Any Matcher
 
Matcher<*>hasParentMatcher<ParentT> ParentMatcher
Matcher<*>hasParentMatcher<*>
Matches AST nodes that have a parent that matches the provided
 matcher.
 
@@ -2177,8 +2147,8 @@ arraySubscriptExpression(hasIndex(integerLiteral()))
 
Matcher<ArrayTypeLoc>hasElementTypeLocMatcher<TypeLoc>
Matches arrays and C99 complex types that have a specific element
+
Matcher<ArrayTypeLoc>hasElementTypeLocMatcher<TypeLoc>
Matches arrays and C99 complex types that have a specific element
 type.
 
 Given
@@ -2192,8 +2162,8 @@ Usable as: Matcher<ArrayType>
hasElementTypeMatcher<Type>
Matches arrays and C99 complex types that have a specific element
+
Matcher<ArrayType>hasElementTypeMatcher<Type>
Matches arrays and C99 complex types that have a specific element
 type.
 
 Given
@@ -2271,8 +2241,8 @@ Example matches b (matcher = binaryOperator(hasRHS()))
 
Matcher<BlockPointerTypeLoc>pointeeLocMatcher<TypeLoc>
Narrows PointerType (and similar) matchers to those where the
+
Matcher<BlockPointerTypeLoc>pointeeLocMatcher<TypeLoc>
Narrows PointerType (and similar) matchers to those where the
 pointee matches a given matcher.
 
 Given
@@ -2287,8 +2257,8 @@ Usable as: Matcher<BlockPointerType>
pointeeMatcher<Type>
Narrows PointerType (and similar) matchers to those where the
+
Matcher<BlockPointerType>pointeeMatcher<Type>
Narrows PointerType (and similar) matchers to those where the
 pointee matches a given matcher.
 
 Given
@@ -2303,17 +2273,65 @@ Usable as: Matcher<CXXConstructExpr>
hasDeclarationMatcher<Decl> InnerMatcher
Matches a type if the declaration of the type matches the given
-matcher.
+
Matcher<CXXConstructExpr>hasAnyArgumentMatcher<Expr> InnerMatcher
Matches any argument of a call expression or a constructor call
+expression.
 
-In addition to being usable as Matcher<TypedefType>, also usable as
-Matcher<T> for any T supporting the getDecl() member function. e.g. various
-subtypes of clang::Type.
+Given
+  void x(int, int, int) { int y; x(1, y, 42); }
+callExpr(hasAnyArgument(declRefExpr()))
+  matches x(1, y, 42)
+with hasAnyArgument(...)
+  matching y
 
-Usable as: Matcher<QualType>, Matcher<CallExpr>, Matcher<CXXConstructExpr>,
-  Matcher<MemberExpr>, Matcher<TypedefType>,
-  Matcher<TemplateSpecializationType>
+FIXME: Currently this will ignore parentheses and implicit casts on
+the argument before applying the inner matcher. We'll want to remove
+this to allow for greater control by the user once ignoreImplicit()
+has been implemented.
+
Matcher<CXXConstructExpr>hasArgumentunsigned N, Matcher<Expr> InnerMatcher
Matches the n'th argument of a call expression or a constructor
+call expression.
+
+Example matches y in x(y)
+    (matcher = callExpr(hasArgument(0, declRefExpr())))
+  void x(int) { int y; x(y); }
+
Matcher<CXXConstructExpr>hasDeclarationMatcher<Decl> InnerMatcher
Matches a node if the declaration associated with that node
+matches the given matcher.
+
+The associated declaration is:
+- for type nodes, the declaration of the underlying type
+- for CallExpr, the declaration of the callee
+- for MemberExpr, the declaration of the referenced member
+- for CXXConstructExpr, the declaration of the constructor
+
+Also usable as Matcher<T> for any T supporting the getDecl() member
+function. e.g. various subtypes of clang::Type and various expressions.
+FIXME: Add all node types for which this is matcher is usable due to
+getDecl().
+
+Usable as: Matcher<CallExpr>, Matcher<CXXConstructExpr>,
+  Matcher<DeclRefExpr>, Matcher<EnumType>, Matcher<InjectedClassNameType>,
+  Matcher<LabelStmt>, Matcher<MemberExpr>, Matcher<QualType>,
+  Matcher<RecordType>, Matcher<TagType>,
+  Matcher<TemplateSpecializationType>, Matcher<TemplateTypeParmType>,
+  Matcher<TypedefType>, Matcher<UnresolvedUsingType>
+
Matcher<CXXConstructorDecl>forEachConstructorInitializerMatcher<CXXCtorInitializer> InnerMatcher
Matches each constructor initializer in a constructor definition.
+
+Given
+  class A { A() : i(42), j(42) {} int i; int j; };
+constructorDecl(forEachConstructorInitializer(forField(decl().bind("x"))))
+  will trigger two matches, binding for 'i' and 'j' respectively.
 
Matcher<CXXMemberCallExpr>thisPointerTypeMatcher<Decl> InnerMatcher
Matcher<CXXMemberCallExpr>thisPointerTypeMatcher<Decl> InnerMatcher
Overloaded to match the type's declaration.
 
Matcher<CallExpr>calleeMatcher<Decl> InnerMatcher
Matcher<CallExpr>calleeMatcher<Decl> InnerMatcher
Matches if the call expression's callee's declaration matches the
 given matcher.
 
@@ -2458,6 +2476,11 @@ callExpr(hasAnyArgument(declRefExpr()))
   matches x(1, y, 42)
 with hasAnyArgument(...)
   matching y
+
+FIXME: Currently this will ignore parentheses and implicit casts on
+the argument before applying the inner matcher. We'll want to remove
+this to allow for greater control by the user once ignoreImplicit()
+has been implemented.
 
Matcher<CallExpr>hasDeclarationMatcher<Decl> InnerMatcher
Matches a type if the declaration of the type matches the given
-matcher.
+
Matcher<CallExpr>hasDeclarationMatcher<Decl> InnerMatcher
Matches a node if the declaration associated with that node
+matches the given matcher.
 
-In addition to being usable as Matcher<TypedefType>, also usable as
-Matcher<T> for any T supporting the getDecl() member function. e.g. various
-subtypes of clang::Type.
+The associated declaration is:
+- for type nodes, the declaration of the underlying type
+- for CallExpr, the declaration of the callee
+- for MemberExpr, the declaration of the referenced member
+- for CXXConstructExpr, the declaration of the constructor
 
-Usable as: Matcher<QualType>, Matcher<CallExpr>, Matcher<CXXConstructExpr>,
-  Matcher<MemberExpr>, Matcher<TypedefType>,
-  Matcher<TemplateSpecializationType>
+Also usable as Matcher<T> for any T supporting the getDecl() member
+function. e.g. various subtypes of clang::Type and various expressions.
+FIXME: Add all node types for which this is matcher is usable due to
+getDecl().
+
+Usable as: Matcher<CallExpr>, Matcher<CXXConstructExpr>,
+  Matcher<DeclRefExpr>, Matcher<EnumType>, Matcher<InjectedClassNameType>,
+  Matcher<LabelStmt>, Matcher<MemberExpr>, Matcher<QualType>,
+  Matcher<RecordType>, Matcher<TagType>,
+  Matcher<TemplateSpecializationType>, Matcher<TemplateTypeParmType>,
+  Matcher<TypedefType>, Matcher<UnresolvedUsingType>
+
Matcher<CaseStmt>hasCaseConstantMatcher<Expr> InnerMatcher
If the given case statement does not use the GNU case range
+extension, matches the constant given in the statement.
+
+Given
+  switch (1) { case 1: case 1+1: case 3 ... 4: ; }
+caseStmt(hasCaseConstant(integerLiteral()))
+  matches "case 1:"
 
Matcher<ComplexTypeLoc>hasElementTypeLocMatcher<TypeLoc>
Matches arrays and C99 complex types that have a specific element
+
Matcher<ComplexTypeLoc>hasElementTypeLocMatcher<TypeLoc>
Matches arrays and C99 complex types that have a specific element
 type.
 
 Given
@@ -2538,8 +2582,8 @@ Usable as: Matcher<ComplexType>
hasElementTypeMatcher<Type>
Matches arrays and C99 complex types that have a specific element
+
Matcher<ComplexType>hasElementTypeMatcher<Type>
Matches arrays and C99 complex types that have a specific element
 type.
 
 Given
@@ -2591,6 +2635,30 @@ Example matches a
 
Matcher<DeclRefExpr>hasDeclarationMatcher<Decl> InnerMatcher
Matches a node if the declaration associated with that node
+matches the given matcher.
+
+The associated declaration is:
+- for type nodes, the declaration of the underlying type
+- for CallExpr, the declaration of the callee
+- for MemberExpr, the declaration of the referenced member
+- for CXXConstructExpr, the declaration of the constructor
+
+Also usable as Matcher<T> for any T supporting the getDecl() member
+function. e.g. various subtypes of clang::Type and various expressions.
+FIXME: Add all node types for which this is matcher is usable due to
+getDecl().
+
+Usable as: Matcher<CallExpr>, Matcher<CXXConstructExpr>,
+  Matcher<DeclRefExpr>, Matcher<EnumType>, Matcher<InjectedClassNameType>,
+  Matcher<LabelStmt>, Matcher<MemberExpr>, Matcher<QualType>,
+  Matcher<RecordType>, Matcher<TagType>,
+  Matcher<TemplateSpecializationType>, Matcher<TemplateTypeParmType>,
+  Matcher<TypedefType>, Matcher<UnresolvedUsingType>
+
Matcher<DeclRefExpr>throughUsingDeclMatcher<UsingShadowDecl> InnerMatcher
Matches a DeclRefExpr that refers to a declaration through a
 specific using shadow declaration.
@@ -2650,6 +2718,17 @@ declStmt(hasSingleDecl(anything()))
 
Matcher<DeclaratorDecl>hasTypeLocMatcher<TypeLoc> Inner
Matches if the type location of the declarator decl's type matches
+the inner matcher.
+
+Given
+  int x;
+declaratorDecl(hasTypeLoc(loc(asString("int"))))
+  matches int x
+
Matcher<Decl>hasDeclContextMatcher<Decl> InnerMatcher
Matches declarations whose declaration context, interpreted as a
 Decl, matches InnerMatcher.
@@ -2722,6 +2801,30 @@ declaration of d.
 
Matcher<EnumType>hasDeclarationMatcher<Decl> InnerMatcher
Matches a node if the declaration associated with that node
+matches the given matcher.
+
+The associated declaration is:
+- for type nodes, the declaration of the underlying type
+- for CallExpr, the declaration of the callee
+- for MemberExpr, the declaration of the referenced member
+- for CXXConstructExpr, the declaration of the constructor
+
+Also usable as Matcher<T> for any T supporting the getDecl() member
+function. e.g. various subtypes of clang::Type and various expressions.
+FIXME: Add all node types for which this is matcher is usable due to
+getDecl().
+
+Usable as: Matcher<CallExpr>, Matcher<CXXConstructExpr>,
+  Matcher<DeclRefExpr>, Matcher<EnumType>, Matcher<InjectedClassNameType>,
+  Matcher<LabelStmt>, Matcher<MemberExpr>, Matcher<QualType>,
+  Matcher<RecordType>, Matcher<TagType>,
+  Matcher<TemplateSpecializationType>, Matcher<TemplateTypeParmType>,
+  Matcher<TypedefType>, Matcher<UnresolvedUsingType>
+
Matcher<ExplicitCastExpr>hasDestinationTypeMatcher<QualType> InnerMatcher
Matches casts whose destination type matches a given matcher.
 
@@ -2730,8 +2833,8 @@ actual casts "explicit" casts.)
 
Matcher<Expr>hasTypeMatcher<Decl> InnerMatcher
Overloaded to match the declaration of the expression's or value
+
Matcher<Expr>hasTypeMatcher<Decl> InnerMatcher
Overloaded to match the declaration of the expression's or value
 declaration's type.
 
 In case of a value declaration (for example a variable declaration),
@@ -2906,7 +3009,7 @@ Example matches true (matcher = hasCondition(boolLiteral(equals(true))))
 
 Given
   if (A* a = GetAPointer()) {}
-hasConditionVariableStatment(...)
+hasConditionVariableStatement(...)
   matches 'A* a = GetAPointer()'.
 
Matcher<MemberExpr>hasDeclarationMatcher<Decl> InnerMatcher
Matches a type if the declaration of the type matches the given
-matcher.
+
Matcher<InjectedClassNameType>hasDeclarationMatcher<Decl> InnerMatcher
Matches a node if the declaration associated with that node
+matches the given matcher.
 
-In addition to being usable as Matcher<TypedefType>, also usable as
-Matcher<T> for any T supporting the getDecl() member function. e.g. various
-subtypes of clang::Type.
+The associated declaration is:
+- for type nodes, the declaration of the underlying type
+- for CallExpr, the declaration of the callee
+- for MemberExpr, the declaration of the referenced member
+- for CXXConstructExpr, the declaration of the constructor
 
-Usable as: Matcher<QualType>, Matcher<CallExpr>, Matcher<CXXConstructExpr>,
-  Matcher<MemberExpr>, Matcher<TypedefType>,
-  Matcher<TemplateSpecializationType>
+Also usable as Matcher<T> for any T supporting the getDecl() member
+function. e.g. various subtypes of clang::Type and various expressions.
+FIXME: Add all node types for which this is matcher is usable due to
+getDecl().
+
+Usable as: Matcher<CallExpr>, Matcher<CXXConstructExpr>,
+  Matcher<DeclRefExpr>, Matcher<EnumType>, Matcher<InjectedClassNameType>,
+  Matcher<LabelStmt>, Matcher<MemberExpr>, Matcher<QualType>,
+  Matcher<RecordType>, Matcher<TagType>,
+  Matcher<TemplateSpecializationType>, Matcher<TemplateTypeParmType>,
+  Matcher<TypedefType>, Matcher<UnresolvedUsingType>
+
Matcher<LabelStmt>hasDeclarationMatcher<Decl> InnerMatcher
Matches a node if the declaration associated with that node
+matches the given matcher.
+
+The associated declaration is:
+- for type nodes, the declaration of the underlying type
+- for CallExpr, the declaration of the callee
+- for MemberExpr, the declaration of the referenced member
+- for CXXConstructExpr, the declaration of the constructor
+
+Also usable as Matcher<T> for any T supporting the getDecl() member
+function. e.g. various subtypes of clang::Type and various expressions.
+FIXME: Add all node types for which this is matcher is usable due to
+getDecl().
+
+Usable as: Matcher<CallExpr>, Matcher<CXXConstructExpr>,
+  Matcher<DeclRefExpr>, Matcher<EnumType>, Matcher<InjectedClassNameType>,
+  Matcher<LabelStmt>, Matcher<MemberExpr>, Matcher<QualType>,
+  Matcher<RecordType>, Matcher<TagType>,
+  Matcher<TemplateSpecializationType>, Matcher<TemplateTypeParmType>,
+  Matcher<TypedefType>, Matcher<UnresolvedUsingType>
+
Matcher<MemberExpr>hasDeclarationMatcher<Decl> InnerMatcher
Matches a node if the declaration associated with that node
+matches the given matcher.
+
+The associated declaration is:
+- for type nodes, the declaration of the underlying type
+- for CallExpr, the declaration of the callee
+- for MemberExpr, the declaration of the referenced member
+- for CXXConstructExpr, the declaration of the constructor
+
+Also usable as Matcher<T> for any T supporting the getDecl() member
+function. e.g. various subtypes of clang::Type and various expressions.
+FIXME: Add all node types for which this is matcher is usable due to
+getDecl().
+
+Usable as: Matcher<CallExpr>, Matcher<CXXConstructExpr>,
+  Matcher<DeclRefExpr>, Matcher<EnumType>, Matcher<InjectedClassNameType>,
+  Matcher<LabelStmt>, Matcher<MemberExpr>, Matcher<QualType>,
+  Matcher<RecordType>, Matcher<TagType>,
+  Matcher<TemplateSpecializationType>, Matcher<TemplateTypeParmType>,
+  Matcher<TypedefType>, Matcher<UnresolvedUsingType>
 
Matcher<MemberPointerTypeLoc>pointeeLocMatcher<TypeLoc>
Narrows PointerType (and similar) matchers to those where the
+
Matcher<MemberPointerTypeLoc>pointeeLocMatcher<TypeLoc>
Narrows PointerType (and similar) matchers to those where the
 pointee matches a given matcher.
 
 Given
@@ -2977,8 +3138,8 @@ Usable as: Matcher<MemberPointerType>
pointeeMatcher<Type>
Narrows PointerType (and similar) matchers to those where the
+
Matcher<MemberPointerType>pointeeMatcher<Type>
Narrows PointerType (and similar) matchers to those where the
 pointee matches a given matcher.
 
 Given
@@ -3072,8 +3233,8 @@ Usable as: Matcher<PointerTypeLoc>
pointeeLocMatcher<TypeLoc>
Narrows PointerType (and similar) matchers to those where the
+
Matcher<PointerTypeLoc>pointeeLocMatcher<TypeLoc>
Narrows PointerType (and similar) matchers to those where the
 pointee matches a given matcher.
 
 Given
@@ -3088,8 +3249,8 @@ Usable as: Matcher<PointerType>
pointeeMatcher<Type>
Narrows PointerType (and similar) matchers to those where the
+
Matcher<PointerType>pointeeMatcher<Type>
Narrows PointerType (and similar) matchers to those where the
 pointee matches a given matcher.
 
 Given
@@ -3117,32 +3278,66 @@ declaration of b but varDecl(hasType(qualType(hasCanonicalType(referenceType()))
 
Matcher<QualType>hasDeclarationMatcher<Decl> InnerMatcher
Matches a type if the declaration of the type matches the given
-matcher.
+
Matcher<QualType>hasDeclarationMatcher<Decl> InnerMatcher
Matches a node if the declaration associated with that node
+matches the given matcher.
 
-In addition to being usable as Matcher<TypedefType>, also usable as
-Matcher<T> for any T supporting the getDecl() member function. e.g. various
-subtypes of clang::Type.
+The associated declaration is:
+- for type nodes, the declaration of the underlying type
+- for CallExpr, the declaration of the callee
+- for MemberExpr, the declaration of the referenced member
+- for CXXConstructExpr, the declaration of the constructor
 
-Usable as: Matcher<QualType>, Matcher<CallExpr>, Matcher<CXXConstructExpr>,
-  Matcher<MemberExpr>, Matcher<TypedefType>,
-  Matcher<TemplateSpecializationType>
+Also usable as Matcher<T> for any T supporting the getDecl() member
+function. e.g. various subtypes of clang::Type and various expressions.
+FIXME: Add all node types for which this is matcher is usable due to
+getDecl().
+
+Usable as: Matcher<CallExpr>, Matcher<CXXConstructExpr>,
+  Matcher<DeclRefExpr>, Matcher<EnumType>, Matcher<InjectedClassNameType>,
+  Matcher<LabelStmt>, Matcher<MemberExpr>, Matcher<QualType>,
+  Matcher<RecordType>, Matcher<TagType>,
+  Matcher<TemplateSpecializationType>, Matcher<TemplateTypeParmType>,
+  Matcher<TypedefType>, Matcher<UnresolvedUsingType>
 
Matcher<QualType>pointsToMatcher<Decl> InnerMatcher
Matcher<QualType>pointsToMatcher<Decl> InnerMatcher
Overloaded to match the pointee type's declaration.
 
Matcher<QualType>referencesMatcher<Decl> InnerMatcher
Matcher<QualType>referencesMatcher<Decl> InnerMatcher
Overloaded to match the referenced type's declaration.
 
Matcher<ReferenceTypeLoc>pointeeLocMatcher<TypeLoc>
Narrows PointerType (and similar) matchers to those where the
+
Matcher<RecordType>hasDeclarationMatcher<Decl> InnerMatcher
Matches a node if the declaration associated with that node
+matches the given matcher.
+
+The associated declaration is:
+- for type nodes, the declaration of the underlying type
+- for CallExpr, the declaration of the callee
+- for MemberExpr, the declaration of the referenced member
+- for CXXConstructExpr, the declaration of the constructor
+
+Also usable as Matcher<T> for any T supporting the getDecl() member
+function. e.g. various subtypes of clang::Type and various expressions.
+FIXME: Add all node types for which this is matcher is usable due to
+getDecl().
+
+Usable as: Matcher<CallExpr>, Matcher<CXXConstructExpr>,
+  Matcher<DeclRefExpr>, Matcher<EnumType>, Matcher<InjectedClassNameType>,
+  Matcher<LabelStmt>, Matcher<MemberExpr>, Matcher<QualType>,
+  Matcher<RecordType>, Matcher<TagType>,
+  Matcher<TemplateSpecializationType>, Matcher<TemplateTypeParmType>,
+  Matcher<TypedefType>, Matcher<UnresolvedUsingType>
+
Matcher<ReferenceTypeLoc>pointeeLocMatcher<TypeLoc>
Narrows PointerType (and similar) matchers to those where the
 pointee matches a given matcher.
 
 Given
@@ -3157,8 +3352,8 @@ Usable as: Matcher<ReferenceType>
pointeeMatcher<Type>
Narrows PointerType (and similar) matchers to those where the
+
Matcher<ReferenceType>pointeeMatcher<Type>
Narrows PointerType (and similar) matchers to those where the
 pointee matches a given matcher.
 
 Given
@@ -3185,6 +3380,43 @@ sizeof.
 
Matcher<SwitchStmt>forEachSwitchCaseMatcher<SwitchCase> InnerMatcher
Matches each case or default statement belonging to the given switch
+statement. This matcher may produce multiple matches.
+
+Given
+  switch (1) { case 1: case 2: default: switch (2) { case 3: case 4: ; } }
+switchStmt(forEachSwitchCase(caseStmt().bind("c"))).bind("s")
+  matches four times, with "c" binding each of "case 1:", "case 2:",
+"case 3:" and "case 4:", and "s" respectively binding "switch (1)",
+"switch (1)", "switch (2)" and "switch (2)".
+
Matcher<TagType>hasDeclarationMatcher<Decl> InnerMatcher
Matches a node if the declaration associated with that node
+matches the given matcher.
+
+The associated declaration is:
+- for type nodes, the declaration of the underlying type
+- for CallExpr, the declaration of the callee
+- for MemberExpr, the declaration of the referenced member
+- for CXXConstructExpr, the declaration of the constructor
+
+Also usable as Matcher<T> for any T supporting the getDecl() member
+function. e.g. various subtypes of clang::Type and various expressions.
+FIXME: Add all node types for which this is matcher is usable due to
+getDecl().
+
+Usable as: Matcher<CallExpr>, Matcher<CXXConstructExpr>,
+  Matcher<DeclRefExpr>, Matcher<EnumType>, Matcher<InjectedClassNameType>,
+  Matcher<LabelStmt>, Matcher<MemberExpr>, Matcher<QualType>,
+  Matcher<RecordType>, Matcher<TagType>,
+  Matcher<TemplateSpecializationType>, Matcher<TemplateTypeParmType>,
+  Matcher<TypedefType>, Matcher<UnresolvedUsingType>
+
Matcher<TemplateArgument>refersToDeclarationMatcher<Decl> InnerMatcher
Matches a TemplateArgument that refers to a certain declaration.
 
@@ -3212,17 +3444,66 @@ classTemplateSpecializationDecl(hasAnyTemplateArgument(
 
Matcher<TemplateSpecializationType>hasDeclarationMatcher<Decl> InnerMatcher
Matches a type if the declaration of the type matches the given
-matcher.
+
Matcher<TemplateSpecializationType>hasDeclarationMatcher<Decl> InnerMatcher
Matches a node if the declaration associated with that node
+matches the given matcher.
 
-In addition to being usable as Matcher<TypedefType>, also usable as
-Matcher<T> for any T supporting the getDecl() member function. e.g. various
-subtypes of clang::Type.
+The associated declaration is:
+- for type nodes, the declaration of the underlying type
+- for CallExpr, the declaration of the callee
+- for MemberExpr, the declaration of the referenced member
+- for CXXConstructExpr, the declaration of the constructor
 
-Usable as: Matcher<QualType>, Matcher<CallExpr>, Matcher<CXXConstructExpr>,
-  Matcher<MemberExpr>, Matcher<TypedefType>,
-  Matcher<TemplateSpecializationType>
+Also usable as Matcher<T> for any T supporting the getDecl() member
+function. e.g. various subtypes of clang::Type and various expressions.
+FIXME: Add all node types for which this is matcher is usable due to
+getDecl().
+
+Usable as: Matcher<CallExpr>, Matcher<CXXConstructExpr>,
+  Matcher<DeclRefExpr>, Matcher<EnumType>, Matcher<InjectedClassNameType>,
+  Matcher<LabelStmt>, Matcher<MemberExpr>, Matcher<QualType>,
+  Matcher<RecordType>, Matcher<TagType>,
+  Matcher<TemplateSpecializationType>, Matcher<TemplateTypeParmType>,
+  Matcher<TypedefType>, Matcher<UnresolvedUsingType>
+
Matcher<TemplateTypeParmType>hasDeclarationMatcher<Decl> InnerMatcher
Matches a node if the declaration associated with that node
+matches the given matcher.
+
+The associated declaration is:
+- for type nodes, the declaration of the underlying type
+- for CallExpr, the declaration of the callee
+- for MemberExpr, the declaration of the referenced member
+- for CXXConstructExpr, the declaration of the constructor
+
+Also usable as Matcher<T> for any T supporting the getDecl() member
+function. e.g. various subtypes of clang::Type and various expressions.
+FIXME: Add all node types for which this is matcher is usable due to
+getDecl().
+
+Usable as: Matcher<CallExpr>, Matcher<CXXConstructExpr>,
+  Matcher<DeclRefExpr>, Matcher<EnumType>, Matcher<InjectedClassNameType>,
+  Matcher<LabelStmt>, Matcher<MemberExpr>, Matcher<QualType>,
+  Matcher<RecordType>, Matcher<TagType>,
+  Matcher<TemplateSpecializationType>, Matcher<TemplateTypeParmType>,
+  Matcher<TypedefType>, Matcher<UnresolvedUsingType>
+
Matcher<T>findAllMatcher<T> Matcher
Matches if the node or any descendant matches.
+
+Generates results for each match.
+
+For example, in:
+  class A { class B {}; class C {}; };
+The matcher:
+  recordDecl(hasName("::A"), findAll(recordDecl(isDefinition()).bind("m")))
+will generate results for A, B and C.
+
+Usable as: Any Matcher
 
Matcher<TypedefType>hasDeclarationMatcher<Decl> InnerMatcher
Matches a type if the declaration of the type matches the given
-matcher.
+
Matches a node if the declaration associated with that node
+matches the given matcher.
 
-In addition to being usable as Matcher<TypedefType>, also usable as
-Matcher<T> for any T supporting the getDecl() member function. e.g. various
-subtypes of clang::Type.
+The associated declaration is:
+- for type nodes, the declaration of the underlying type
+- for CallExpr, the declaration of the callee
+- for MemberExpr, the declaration of the referenced member
+- for CXXConstructExpr, the declaration of the constructor
 
-Usable as: Matcher<QualType>, Matcher<CallExpr>, Matcher<CXXConstructExpr>,
-  Matcher<MemberExpr>, Matcher<TypedefType>,
-  Matcher<TemplateSpecializationType>
+Also usable as Matcher<T> for any T supporting the getDecl() member
+function. e.g. various subtypes of clang::Type and various expressions.
+FIXME: Add all node types for which this is matcher is usable due to
+getDecl().
+
+Usable as: Matcher<CallExpr>, Matcher<CXXConstructExpr>,
+  Matcher<DeclRefExpr>, Matcher<EnumType>, Matcher<InjectedClassNameType>,
+  Matcher<LabelStmt>, Matcher<MemberExpr>, Matcher<QualType>,
+  Matcher<RecordType>, Matcher<TagType>,
+  Matcher<TemplateSpecializationType>, Matcher<TemplateTypeParmType>,
+  Matcher<TypedefType>, Matcher<UnresolvedUsingType>
 
Matcher<UnresolvedUsingType>hasDeclarationMatcher<Decl> InnerMatcher
Matches a node if the declaration associated with that node
+matches the given matcher.
+
+The associated declaration is:
+- for type nodes, the declaration of the underlying type
+- for CallExpr, the declaration of the callee
+- for MemberExpr, the declaration of the referenced member
+- for CXXConstructExpr, the declaration of the constructor
+
+Also usable as Matcher<T> for any T supporting the getDecl() member
+function. e.g. various subtypes of clang::Type and various expressions.
+FIXME: Add all node types for which this is matcher is usable due to
+getDecl().
+
+Usable as: Matcher<CallExpr>, Matcher<CXXConstructExpr>,
+  Matcher<DeclRefExpr>, Matcher<EnumType>, Matcher<InjectedClassNameType>,
+  Matcher<LabelStmt>, Matcher<MemberExpr>, Matcher<QualType>,
+  Matcher<RecordType>, Matcher<TagType>,
+  Matcher<TemplateSpecializationType>, Matcher<TemplateTypeParmType>,
+  Matcher<TypedefType>, Matcher<UnresolvedUsingType>
+
Matcher<UsingDecl>hasAnyUsingShadowDeclMatcher<UsingShadowDecl> InnerMatcher
Matches any using shadow declaration.
 
@@ -3286,8 +3601,8 @@ usingDecl(hasAnyUsingShadowDecl(hasTargetDecl(functionDecl())))
   matches using X::b but not using X::a 
Matcher<ValueDecl>hasTypeMatcher<Decl> InnerMatcher
Overloaded to match the declaration of the expression's or value
+
Matcher<ValueDecl>hasTypeMatcher<Decl> InnerMatcher
Overloaded to match the declaration of the expression's or value
 declaration's type.
 
 In case of a value declaration (for example a variable declaration),
diff --git a/docs/LibTooling.rst b/docs/LibTooling.rst
index a9c24c304545..505865606433 100644
--- a/docs/LibTooling.rst
+++ b/docs/LibTooling.rst
@@ -176,7 +176,7 @@ Builtin includes
 
 Clang tools need their builtin headers and search for them the same way Clang
 does.  Thus, the default location to look for builtin headers is in a path
-``$(dirname /path/to/tool)/../lib/clang/3.3/include`` relative to the tool
+``$(dirname /path/to/tool)/../lib/clang/3.4/include`` relative to the tool
 binary.  This works out-of-the-box for tools running from llvm's toplevel
 binary directory after building clang-headers, or if the tool is running from
 the binary directory of a clang install next to the clang binary.
diff --git a/docs/Makefile b/docs/Makefile
index 2608046f1f85..a76ce024e73c 100644
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -19,7 +19,12 @@ $(PROJ_OBJ_DIR)/doxygen.cfg: doxygen.cfg.in
 	  -e 's/@abs_srcdir@/./g' \
 	  -e 's/@DOT@/dot/g' \
 	  -e 's/@PACKAGE_VERSION@/mainline/' \
-	  -e 's/@abs_builddir@/./g' > $@
+	  -e 's/@abs_builddir@/./g' \
+	  -e 's/@enable_searchengine@/NO/g' \
+	  -e 's/@searchengine_url@//g' \
+	  -e 's/@enable_server_based_search@/NO/g' \
+	  -e 's/@enable_external_search@/NO/g' \
+	  -e 's/@extra_search_mappings@//g' > $@
 endif
 
 include $(CLANG_LEVEL)/Makefile
@@ -73,10 +78,10 @@ doxygen: regendoc $(PROJ_OBJ_DIR)/doxygen.tar.gz
 
 regendoc:
 	$(Echo) Building doxygen documentation
-	$(Verb) if test -e $(PROJ_OBJ_DIR)/doxygen ; then \
-	  $(RM) -rf $(PROJ_OBJ_DIR)/doxygen ; \
-	fi
+	$(Verb) $(RM) -rf $(PROJ_OBJ_DIR)/doxygen
 	$(Verb) $(DOXYGEN) $(PROJ_OBJ_DIR)/doxygen.cfg
+	$(Verb) sed -i "s/[$$]LatestRev[$$]/`svnversion $(PROJ_SRC_DIR)`/g" \
+	 $(PROJ_OBJ_DIR)/doxygen/html/*.html
 
 $(PROJ_OBJ_DIR)/doxygen.tar.gz: $(DOXYFILES) $(PROJ_OBJ_DIR)/doxygen.cfg
 	$(Echo) Packaging doxygen documentation
diff --git a/docs/MemorySanitizer.rst b/docs/MemorySanitizer.rst
index 439acc47fa26..5fc7e745d19f 100644
--- a/docs/MemorySanitizer.rst
+++ b/docs/MemorySanitizer.rst
@@ -90,8 +90,16 @@ to disable uninitialized checks in a particular function.
 MemorySanitizer may still instrument such functions to avoid false positives.
 This attribute may not be
 supported by other compilers, so we suggest to use it together with
-``__has_feature(memory_sanitizer)``. Note: currently, this attribute will be
-lost if the function is inlined.
+``__has_feature(memory_sanitizer)``.
+
+Blacklist
+---------
+
+MemorySanitizer supports ``src`` and ``fun`` entity types in
+:doc:`SanitizerSpecialCaseList`, that can be used to relax MemorySanitizer
+checks for certain source files and functions. All "Use of uninitialized value"
+warnings will be suppressed and all values loaded from memory will be
+considered fully initialized.
 
 Origin Tracking
 ===============
diff --git a/docs/Modules.rst b/docs/Modules.rst
index fdf597a5a926..9fb4c774874c 100644
--- a/docs/Modules.rst
+++ b/docs/Modules.rst
@@ -2,13 +2,13 @@
 Modules
 =======
 
+.. warning::
+   The functionality described on this page is supported for C and
+   Objective-C. C++ support is experimental.
+
 .. contents::
    :local:
 
-.. warning::
-   The functionality described on this page is still experimental! Please
-   try it out and send us bug reports!
-
 Introduction
 ============
 Most software is built using a number of software libraries, including libraries supplied by the platform, internal libraries built as part of the software itself to provide structure, and third-party libraries. For each library, one needs to access both its interface (API) and its implementation. In the C family of languages, the interface to a library is accessed by including the appropriate header files(s):
@@ -106,24 +106,25 @@ Using Modules
 =============
 To enable modules, pass the command-line flag ``-fmodules`` [#]_. This will make any modules-enabled software libraries available as modules as well as introducing any modules-specific syntax. Additional `command-line parameters`_ are described in a separate section later.
 
-Import declaration
-------------------
-The most direct way to import a module is with an *import declaration*, which imports the named module:
+Objective-C Import declaration
+------------------------------
+Objective-C provides syntax for importing a module via an *@import declaration*, which imports the named module:
 
 .. parsed-literal::
 
-  import std;
+  @import std;
 
-The import declaration above imports the entire contents of the ``std`` module (which would contain, e.g., the entire C or C++ standard library) and make its API available within the current translation unit. To import only part of a module, one may use dot syntax to specific a particular submodule, e.g.,
+The @import declaration above imports the entire contents of the ``std`` module (which would contain, e.g., the entire C or C++ standard library) and make its API available within the current translation unit. To import only part of a module, one may use dot syntax to specific a particular submodule, e.g.,
 
 .. parsed-literal::
 
-  import std.io;
+  @import std.io;
 
 Redundant import declarations are ignored, and one is free to import modules at any point within the translation unit, so long as the import declaration is at global scope.
 
-.. warning::
-  The import declaration syntax described here does not actually exist. Rather, it is a straw man proposal that may very well change when modules are discussed in the C and C++ committees. See the section `Includes as imports`_ to see how modules get imported today.
+At present, there is no C or C++ syntax for import declarations. Clang
+will track the modules proposal in the C++ committee. See the section
+`Includes as imports`_ to see how modules get imported today.
 
 Includes as imports
 -------------------
@@ -148,6 +149,8 @@ Module maps are specified as separate files (each named ``module.map``) alongsid
 .. note::
 
   To actually see any benefits from modules, one first has to introduce module maps for the underlying C standard library and the libraries and headers on which it depends. The section `Modularizing a Platform`_ describes the steps one must take to write these module maps.
+  
+One can use module maps without modules to check the integrity of the use of header files. To do this, use the ``-fmodule-maps`` option instead of the ``-fmodules`` option.
 
 Compilation model
 -----------------
@@ -165,6 +168,9 @@ Command-line parameters
 ``-fcxx-modules``
   Enable the modules feature for C++ (EXPERIMENTAL and VERY BROKEN).
 
+``-fmodule-maps``
+  Enable interpretation of module maps (EXPERIMENTAL). This option is implied by ``-fmodules``.
+
 ``-fmodules-cache-path=``
   Specify the path to the modules cache. If not provided, Clang will select a system-appropriate default.
 
@@ -183,6 +189,15 @@ Command-line parameters
 ``-module-file-info ``
   Debugging aid that prints information about a given module file (with a ``.pcm`` extension), including the language and preprocessor options that particular module variant was built with.
 
+``-fmodules-decluse``
+  Enable checking of module ``use`` declarations.
+
+``-fmodule-name=module-id``
+  Consider a source file as a part of the given module.
+
+``-fmodule-map-file=``
+  Load the given module map file if a header from its directory or one of its subdirectories is loaded.
+
 Module Map Language
 ===================
 
@@ -231,8 +246,9 @@ Module map files use a simplified form of the C99 lexer, with the same rules for
 
   ``config_macros`` ``export``     ``module``
   ``conflict``      ``framework``  ``requires``
-  ``exclude``       ``header``     ``umbrella``
-  ``explicit``      ``link``
+  ``exclude``       ``header``     ``private``
+  ``explicit``      ``link``       ``umbrella``
+  ``extern``        ``use``
 
 Module map file
 ---------------
@@ -258,6 +274,7 @@ A module declaration describes a module, including the headers that contribute t
 
   *module-declaration*:
     ``explicit``:sub:`opt` ``framework``:sub:`opt` ``module`` *module-id* *attributes*:sub:`opt` '{' *module-member** '}'
+    ``extern`` ``module`` *module-id* *string-literal*
 
 The *module-id* should consist of only a single *identifier*, which provides the name of the module being defined. Each module shall have a single definition. 
 
@@ -286,10 +303,13 @@ Modules can have a number of different kinds of members, each of which is descri
     *umbrella-dir-declaration*
     *submodule-declaration*
     *export-declaration*
+    *use-declaration*
     *link-declaration*
     *config-macros-declaration*
     *conflict-declaration*
 
+An extern module references a module defined by the *module-id* in a file given by the *string-literal*. The file can be referenced either by an absolute path or by a path relative to the current map file.
+
 Requires declaration
 ~~~~~~~~~~~~~~~~~~~~
 A *requires-declaration* specifies the requirements that an importing translation unit must satisfy to use the module.
@@ -300,9 +320,12 @@ A *requires-declaration* specifies the requirements that an importing translatio
     ``requires`` *feature-list*
 
   *feature-list*:
-    *identifier* (',' *identifier*)*
+    *feature* (',' *feature*)*
 
-The requirements clause allows specific modules or submodules to specify that they are only accessible with certain language dialects or on certain platforms. The feature list is a set of identifiers, defined below. If any of the features is not available in a given translation unit, that translation unit shall not import the module.
+  *feature*:
+    ``!``:sub:`opt` *identifier*
+
+The requirements clause allows specific modules or submodules to specify that they are only accessible with certain language dialects or on certain platforms. The feature list is a set of identifiers, defined below. If any of the features is not available in a given translation unit, that translation unit shall not import the module. The optional ``!`` indicates that a feature is incompatible with the module.
 
 The following features are defined:
 
@@ -360,6 +383,7 @@ A header declaration specifies that a particular header is associated with the e
 
   *header-declaration*:
     ``umbrella``:sub:`opt` ``header`` *string-literal*
+    ``private`` ``header`` *string-literal*
     ``exclude`` ``header`` *string-literal*
 
 A header declaration that does not contain ``exclude`` specifies a header that contributes to the enclosing module. Specifically, when the module is built, the named header will be parsed and its declarations will be (logically) placed into the enclosing submodule.
@@ -372,6 +396,8 @@ A header with the ``umbrella`` specifier is called an umbrella header. An umbrel
     ``-Wincomplete-umbrella`` warning option to ask Clang to complain
     about headers not covered by the umbrella header or the module map.
 
+A header with the ``private`` specifier may not be included from outside the module itself.
+
 A header with the ``exclude`` specifier is excluded from the module. It will not be included when the module is built, nor will it be considered to be part of the module.
 
 **Example**: The C header ``assert.h`` is an excellent candidate for an excluded header, because it is meant to be included multiple times (possibly with different ``NDEBUG`` settings).
@@ -521,6 +547,36 @@ Note that, if ``Derived.h`` includes ``Base.h``, one can simply use a wildcard e
   compatibility for programs that rely on transitive inclusion (i.e.,
   all of them).
 
+Use declaration
+~~~~~~~~~~~~~~~
+A *use-declaration* specifies one of the other modules that the module is allowed to use. An import or include not matching one of these is rejected when the option *-fmodules-decluse*.
+
+.. parsed-literal::
+
+  *use-declaration*:
+    ``use`` *module-id*
+
+**Example**:: In the following example, use of A from C is not declared, so will trigger a warning.
+
+.. parsed-literal::
+
+  module A {
+    header "a.h"
+  }
+
+  module B {
+    header "b.h"
+  }
+
+  module C {
+    header "c.h"
+    use B
+  }
+
+When compiling a source file that implements a module, use the option ``-fmodule-name=``module-id to indicate that the source file is logically part of that module.
+
+The compiler at present only applies restrictions to the module directly being built.
+
 Link declaration
 ~~~~~~~~~~~~~~~~
 A *link-declaration* specifies a library or framework against which a program should be linked if the enclosing module is imported in any translation unit in that program.
diff --git a/docs/ObjectiveCLiterals.rst b/docs/ObjectiveCLiterals.rst
index 92e4fb65cd29..8066d8f6bead 100644
--- a/docs/ObjectiveCLiterals.rst
+++ b/docs/ObjectiveCLiterals.rst
@@ -218,12 +218,6 @@ character data is valid. Passing ``NULL`` as the character pointer will
 raise an exception at runtime. When possible, the compiler will reject
 ``NULL`` character pointers used in boxed expressions.
 
-Availability
-------------
-
-Boxed expressions will be available in clang 3.2. It is not currently
-available in any Apple compiler.
-
 Container Literals
 ==================
 
diff --git a/docs/ReleaseNotes.rst b/docs/ReleaseNotes.rst
index e764a09d5363..ec0dbffed079 100644
--- a/docs/ReleaseNotes.rst
+++ b/docs/ReleaseNotes.rst
@@ -1,40 +1,56 @@
 =======================
-Clang 3.3 Release Notes
+Clang 3.4 Release Notes
 =======================
 
 .. contents::
    :local:
    :depth: 2
 
-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
-`_.
+frontend, part of the LLVM Compiler Infrastructure, release 3.4. 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 `_.
+For more information about Clang or LLVM, including information about
+the latest release, please check out the main `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 `_.
+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?
+What's New in Clang 3.4?
 ========================
 
 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.
+infrastructure are described first, followed by language-specific
+sections with improvements to Clang's support for those languages.
+
+Last release which will build as C++98
+--------------------------------------
+
+This is expected to be the last release of Clang which compiles using a C++98
+toolchain. We expect to start using some C++11 features in Clang starting after
+this release. That said, we are committed to supporting a reasonable set of
+modern C++ toolchains as the host compiler on all of the platforms. This will
+at least include Visual Studio 2012 on Windows, and Clang 3.1 or GCC 4.7.x on
+Mac and Linux. The final set of compilers (and the C++11 features they support)
+is not set in stone, but we wanted users of Clang to have a heads up that the
+next release will involve a substantial change in the host toolchain
+requirements.
+
+Note that this change is part of a change for the entire LLVM project, not just
+Clang.
 
 Major New Features
 ------------------
@@ -44,90 +60,210 @@ Improvements to Clang's diagnostics
 
 Clang's diagnostics are constantly being improved to catch more issues,
 explain them more clearly, and provide more accurate source information
-about them. The improvements since the 3.2 release include:
+about them. The improvements since the 3.3 release include:
 
-Extended Identifiers: Unicode Support and Universal Character Names
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+- -Wheader-guard warns on mismatches between the #ifndef and #define lines
+  in a header guard.
 
-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``).
+  .. code-block:: c
+
+    #ifndef multiple
+    #define multi
+    #endif
+
+  returns
+  `warning: 'multiple' is used as a header guard here, followed by #define of a different macro [-Wheader-guard]`
+
+- -Wlogical-not-parentheses warns when a logical not ('!') only applies to the
+  left-hand side of a comparison.  This warning is part of -Wparentheses.
+
+  .. code-block:: c++
+
+    int i1 = 0, i2 = 1;
+    bool ret;
+    ret = !i1 == i2;
+
+  returns
+  `warning: logical not is only applied to the left hand side of this comparison [-Wlogical-not-parentheses]`
+
+
+- Boolean increment, a deprecated feature, has own warning flag
+  -Wdeprecated-increment-bool, and is still part of -Wdeprecated.
+- Clang errors on builtin enum increments and decrements.
+
+  .. code-block:: c++
+
+    enum A { A1, A2 };
+    void test() {
+    	A a;
+    	a++;
+    }
+
+  returns
+  `error: must use 'enum' tag to refer to type 'A'`
+
+
+- -Wloop-analysis now warns on for-loops which have the same increment or
+  decrement in the loop header as the last statement in the loop.
+
+  .. code-block:: c
+
+    void foo(char *a, char *b, unsigned c) {
+	  for (unsigned i = 0; i < c; ++i) {
+		a[i] = b[i];
+		++i;
+	  }
+    }
+
+  returns
+  `warning: variable 'i' is incremented both in the loop header and in the loop body [-Wloop-analysis]`
+
+- -Wuninitialized now performs checking across field initializers to detect
+  when one field in used uninitialized in another field initialization.
+
+  .. code-block:: c++
+
+    class A {
+      int x;
+      int y;
+      A() : x(y) {}
+    };
+
+  returns
+  `warning: field 'y' is uninitialized when used here [-Wuninitialized]`
+
+- Clang can detect initializer list use inside a macro and suggest parentheses
+  if possible to fix.
+- Many improvements to Clang's typo correction facilities, such as:
+
+  + Adding global namespace qualifiers so that corrections can refer to shadowed
+    or otherwise ambiguous or unreachable namespaces.
+  + Including accessible class members in the set of typo correction candidates,
+    so that corrections requiring a class name in the name specifier are now
+    possible.
+  + Allowing typo corrections that involve removing a name specifier.
+  + In some situations, correcting function names when a function was given the
+    wrong number of arguments, including situations where the original function
+    name was correct but was shadowed by a lexically closer function with the
+    same name yet took a different number of arguments.
+  + Offering typo suggestions for 'using' declarations.
+  + Providing better diagnostics and fixit suggestions in more situations when
+    a '->' was used instead of '.' or vice versa.
+  + Providing more relevant suggestions for typos followed by '.' or '='.
+  + Various performance improvements when searching for typo correction
+    candidates.
+
+- `LeakSanitizer `_ is an experimental memory leak detector
+  which can be combined with AddressSanitizer.
+
+New Compiler Flags
+------------------
+
+- Clang no longer special cases -O4 to enable lto. Explicitly pass -flto to
+  enable it.
+- Clang no longer fails on >= -O5. These flags are mapped to -O3 instead.
+- Command line "clang -O3 -flto a.c -c" and "clang -emit-llvm a.c -c"
+  are no longer equivalent.
+- Clang now errors on unknown -m flags (``-munknown-to-clang``),
+  unknown -f flags (``-funknown-to-clang``) and unknown
+  options (``-what-is-this``).
 
 C Language Changes in Clang
 ---------------------------
 
+- Added new checked arithmetic builtins for security critical applications.
+
 C++ Language Changes in Clang
 -----------------------------
 
-- 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.
+- Fixed an ABI regression, introduced in Clang 3.2, which affected
+  member offsets for classes inheriting from certain classes with tail padding.
+  See PR16537.
+
+- Clang 3.4 supports the 2013-08-28 draft of the ISO WG21 SG10 feature test
+  macro recommendations. These aim to provide a portable method to determine
+  whether a compiler supports a language feature, much like Clang's
+  |has_feature macro|_.
+
+.. |has_feature macro| replace:: ``__has_feature`` macro
+.. _has_feature macro: LanguageExtensions.html#has-feature-and-has-extension
+
+C++1y Feature Support
+^^^^^^^^^^^^^^^^^^^^^
+
+Clang 3.4 supports all the features in the current working draft of the
+upcoming C++ standard, provisionally named C++1y. Support for the following
+major new features has been added since Clang 3.3:
+
+- Generic lambdas and initialized lambda captures.
+- Deduced function return types (``auto f() { return 0; }``).
+- Generalized ``constexpr`` support (variable mutation and loops).
+- Variable templates and static data member templates.
+- Use of ``'`` as a digit separator in numeric literals.
+- Support for sized ``::operator delete`` functions.
+
+In addition, ``[[deprecated]]`` is now accepted as a synonym for Clang's
+existing ``deprecated`` attribute.
+
+Use ``-std=c++1y`` to enable C++1y mode.
+
+OpenCL C Language Changes in Clang
+----------------------------------
+
+- OpenCL C "long" now always has a size of 64 bit, and all OpenCL C
+  types are aligned as specified in the OpenCL C standard. Also,
+  "char" is now always signed.
 
 Internal API Changes
 --------------------
 
-These are major API changes that have happened since the 3.2 release of
+These are major API changes that have happened since the 3.3 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
-^^^^^^^^^^^^^
+Wide Character Types
+^^^^^^^^^^^^^^^^^^^^
 
-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 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.
+The ASTContext class now keeps track of two different types for wide character
+types: WCharTy and WideCharTy. WCharTy represents the built-in wchar_t type
+available in C++. WideCharTy is the type used for wide character literals; in
+C++ it is the same as WCharTy, but in C99, where wchar_t is a typedef, it is an
+integer type.
 
 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.
+The static analyzer has been greatly improved. This impacts the overall analyzer quality and reduces a number of false positives.
+In particular, this release provides enhanced C++ support, reasoning about initializer lists, zeroing constructors, noreturn destructors and modeling of destructor calls on calls to delete.
 
-Core Analysis Improvements
-==========================
+Clang Format
+------------
 
-- 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
+Clang now includes a new tool ``clang-format`` which can be used to
+automatically format C, C++ and Objective-C source code. ``clang-format``
+automatically chooses linebreaks and indentation and can be easily integrated
+into editors, IDEs and version control systems. It supports several pre-defined
+styles as well as precise style control using a multitude of formatting
+options. ``clang-format`` itself is just a thin wrapper around a library which
+can also be used directly from code refactoring and code translation tools.
+More information can be found on `Clang Format's
+site `_.
 
-New Issues Found
-================
+Windows Support
+---------------
 
-- 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.
+- `clang-cl `_ provides a new driver mode that is
+  designed for compatibility with Visual Studio's compiler, cl.exe. This driver
+  mode makes Clang accept the same kind of command-line options as cl.exe. The
+  installer will attempt to expose clang-cl in any Visual Studio installations
+  on the system as a Platform Toolset, e.g. "LLVM-vs2012". clang-cl targets the
+  Microsoft ABI by default. Please note that this driver mode and compatibility
+  with the MS ABI is highly experimental.
+
+Python Binding Changes
+----------------------
+
+The following methods have been added:
 
 Significant Known Problems
 ==========================
@@ -135,11 +271,13 @@ Significant Known Problems
 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.
+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 revision 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 `_.
+If you have any questions or comments about Clang, please feel free to
+contact us via the `mailing
+list `_.
diff --git a/docs/SanitizerSpecialCaseList.rst b/docs/SanitizerSpecialCaseList.rst
new file mode 100644
index 000000000000..8f4727c2fbc3
--- /dev/null
+++ b/docs/SanitizerSpecialCaseList.rst
@@ -0,0 +1,79 @@
+===========================
+Sanitizer special case list
+===========================
+
+.. contents::
+   :local:
+
+Introduction
+============
+
+This document describes the way to disable or alter the behavior of
+sanitizer tools for certain source-level entities by providing a special
+file at compile-time.
+
+Goal and usage
+==============
+
+User of sanitizer tools, such as :doc:`AddressSanitizer`, :doc:`ThreadSanitizer`
+or :doc:`MemorySanitizer` may want to disable or alter some checks for
+certain source-level entities to:
+
+* speedup hot function, which is known to be correct;
+* ignore a function that does some low-level magic (e.g. walks through the
+  thread stack, bypassing the frame boundaries);
+* ignore a known problem.
+
+To achieve this, user may create a file listing the entities he wants to
+ignore, and pass it to clang at compile-time using
+``-fsanitize-blacklist`` flag. See :doc:`UsersManual` for details.
+
+Example
+=======
+
+.. code-block:: bash
+
+  $ cat foo.c
+  #include 
+  void bad_foo() {
+    int *a = (int*)malloc(40);
+    a[10] = 1;
+  }
+  int main() { bad_foo(); }
+  $ cat blacklist.txt
+  # Ignore reports from bad_foo function.
+  fun:bad_foo
+  $ clang -fsanitize=address foo.c ; ./a.out
+  # AddressSanitizer prints an error report.
+  $ clang -fsanitize=address -fsanitize-blacklist=blacklist.txt foo.c ; ./a.out
+  # No error report here.
+
+Format
+======
+
+Each line contains an entity type, followed by a colon and a regular
+expression, specifying the names of the entities, optionally followed by
+an equals sign and a tool-specific category. Empty lines and lines starting
+with "#" are ignored. The meanining of ``*`` in regular expression for entity
+names is different - it is treated as in shell wildcarding. Two generic
+entity types are ``src`` and ``fun``, which allow user to add, respectively,
+source files and functions to special case list. Some sanitizer tools may
+introduce custom entity types - refer to tool-specific docs.
+
+.. code-block:: bash
+
+    # Lines starting with # are ignored.
+    # Turn off checks for the source file (use absolute path or path relative
+    # to the current working directory):
+    src:/path/to/source/file.c
+    # Turn off checks for a particular functions (use mangled names):
+    fun:MyFooBar
+    fun:_Z8MyFooBarv
+    # Extended regular expressions are supported:
+    fun:bad_(foo|bar)
+    src:bad_source[1-9].c
+    # Shell like usage of * is supported (* is treated as .*):
+    src:bad/sources/*
+    fun:*BadFunction*
+    # Specific sanitizer tools may introduce categories.
+    src:/special/path/*=special_sources
diff --git a/docs/ThreadSanitizer.rst b/docs/ThreadSanitizer.rst
index 5e5ee48f7f44..194ad4a8efb0 100644
--- a/docs/ThreadSanitizer.rst
+++ b/docs/ThreadSanitizer.rst
@@ -91,11 +91,21 @@ Some code should not be instrumented by ThreadSanitizer.
 One may use the function attribute
 :ref:`no_sanitize_thread `
 to disable instrumentation of plain (non-atomic) loads/stores in a particular function.
-ThreadSanitizer may still instrument such functions to avoid false positives.
+ThreadSanitizer still instruments such functions to avoid false positives and
+provide meaningful stack traces.
 This attribute may not be
 supported by other compilers, so we suggest to use it together with
-``__has_feature(thread_sanitizer)``. Note: currently, this attribute will be
-lost if the function is inlined.
+``__has_feature(thread_sanitizer)``.
+
+Blacklist
+---------
+
+ThreadSanitizer supports ``src`` and ``fun`` entity types in
+:doc:`SanitizerSpecialCaseList`, that can be used to suppress data race reports in
+the specified source files or functions. Unlike functions marked with
+:ref:`no_sanitize_thread ` attribute,
+blacklisted functions are not instrumented at all. This can lead to false positives
+due to missed synchronization via atomic operations and missed stack frames in reports.
 
 Limitations
 -----------
diff --git a/docs/UsersManual.rst b/docs/UsersManual.rst
index 3dc07aba9013..96d65a47d1b8 100644
--- a/docs/UsersManual.rst
+++ b/docs/UsersManual.rst
@@ -44,6 +44,8 @@ as to improve functionality through Clang-specific features. The Clang
 driver and language features are intentionally designed to be as
 compatible with the GNU GCC compiler as reasonably possible, easing
 migration from GCC to Clang. In most cases, code "just works".
+Clang also provides an alternative driver, :ref:`clang-cl`, that is designed
+to be compatible with the Visual C++ compiler, cl.exe.
 
 In addition to language specific features, Clang has a variety of
 features that depend on what CPU architecture or operating system is
@@ -235,6 +237,11 @@ output format of the diagnostics that it generates.
                 ^
                 //
 
+**-fansi-escape-codes**
+   Controls whether ANSI escape codes are used instead of the Windows Console
+   API to output colored diagnostics. This option is only used on Windows and
+   defaults to off.
+
 .. option:: -fdiagnostics-format=clang/msvc/vi
 
    Changes diagnostic output format to better match IDEs and command line tools.
@@ -422,7 +429,7 @@ output format of the diagnostics that it generates.
            map<
              [...],
              map<
-               [float != float],
+               [float != double],
                [...]>>>
 
 .. _cl_diag_warning_groups:
@@ -853,7 +860,7 @@ Controlling Code Generation
 Clang provides a number of ways to control code generation. The options
 are listed below.
 
-**-fsanitize=check1,check2,...**
+**-f[no-]sanitize=check1,check2,...**
    Turn on runtime checks for various forms of undefined or suspicious
    behavior.
 
@@ -889,13 +896,14 @@ are listed below.
       includes all of the checks listed below other than
       ``unsigned-integer-overflow``.
 
-      ``-fsanitize=undefined-trap``: This includes all sanitizers
+   -  ``-fsanitize=undefined-trap``: This includes all sanitizers
       included by ``-fsanitize=undefined``, except those that require
-      runtime support.  This group of sanitizers are generally used
-      in conjunction with the ``-fsanitize-undefined-trap-on-error``
-      flag, which causes traps to be emitted, rather than calls to
-      runtime libraries. This includes all of the checks listed below
-      other than ``unsigned-integer-overflow`` and ``vptr``.
+      runtime support. This group of sanitizers is intended to be
+      used in conjunction with the ``-fsanitize-undefined-trap-on-error``
+      flag. This includes all of the checks listed below other than
+      ``unsigned-integer-overflow`` and ``vptr``.
+   -  ``-fsanitize=dataflow``: :doc:`DataFlowSanitizer`, a general data
+      flow analysis.
 
    The following more fine-grained checks are also available:
 
@@ -913,6 +921,8 @@ are listed below.
       destination.
    -  ``-fsanitize=float-divide-by-zero``: Floating point division by
       zero.
+   -  ``-fsanitize=function``: Indirect call of a function through a
+      function pointer of the wrong type (Linux, C++ and x86/x86_64 only).
    -  ``-fsanitize=integer-divide-by-zero``: Integer division by zero.
    -  ``-fsanitize=null``: Use of a null pointer or creation of a null
       reference.
@@ -941,6 +951,15 @@ are listed below.
       it is of the wrong dynamic type, or that its lifetime has not
       begun or has ended. Incompatible with ``-fno-rtti``.
 
+   You can turn off or modify checks for certain source files, functions
+   or even variables by providing a special file:
+
+   -  ``-fsanitize-blacklist=/path/to/blacklist/file``: disable or modify
+      sanitizer checks for objects listed in the file. See
+      :doc:`SanitizerSpecialCaseList` for file format description.
+   -  ``-fno-sanitize-blacklist``: don't use blacklist file, if it was
+      specified earlier in the command line.
+
    Experimental features of AddressSanitizer (not ready for widespread
    use, require explicit ``-fsanitize=address``):
 
@@ -958,10 +977,31 @@ are listed below.
       uninitialized bits came from. Slows down execution by additional
       1.5x-2x.
 
+   Extra features of UndefinedBehaviorSanitizer:
+
+   -  ``-fno-sanitize-recover``: By default, after a sanitizer diagnoses
+      an issue, it will attempt to continue executing the program if there
+      is a reasonable behavior it can give to the faulting operation. This
+      option causes the program to abort instead.
+   -  ``-fsanitize-undefined-trap-on-error``: Causes traps to be emitted
+      rather than calls to runtime libraries when a problem is detected.
+      This option is intended for use in cases where the sanitizer runtime
+      cannot be used (for instance, when building libc or a kernel module).
+      This is only compatible with the sanitizers in the ``undefined-trap``
+      group.
+
    The ``-fsanitize=`` argument must also be provided when linking, in
-   order to link to the appropriate runtime library. It is not possible
-   to combine the ``-fsanitize=address`` and ``-fsanitize=thread``
-   checkers in the same program.
+   order to link to the appropriate runtime library. When using
+   ``-fsanitize=vptr`` (or a group that includes it, such as
+   ``-fsanitize=undefined``) with a C++ program, the link must be
+   performed by ``clang++``, not ``clang``, in order to link against the
+   C++-specific parts of the runtime library.
+
+   It is not possible to combine more than one of the ``-fsanitize=address``,
+   ``-fsanitize=thread``, and ``-fsanitize=memory`` checkers in the same
+   program. The ``-fsanitize=undefined`` checks can be combined with other
+   sanitizers.
+
 **-f[no-]address-sanitizer**
    Deprecated synonym for :ref:`-f[no-]sanitize=address
    `.
@@ -1007,6 +1047,26 @@ are listed below.
    efficient model can be used. The TLS model can be overridden per
    variable using the ``tls_model`` attribute.
 
+.. option:: -mhwdiv=[values]
+
+   Select the ARM modes (arm or thumb) that support hardware division
+   instructions.
+
+   Valid values are: ``arm``, ``thumb`` and ``arm,thumb``.
+   This option is used to indicate which mode (arm or thumb) supports
+   hardware division instructions. This only applies to the ARM
+   architecture.
+
+.. option:: -m[no-]crc
+
+   Enable or disable CRC instructions.
+
+   This option is used to indicate whether CRC instructions are to
+   be generated. This only applies to the ARM architecture.
+
+   CRC instructions are enabled by default on ARMv8.
+
+
 Controlling Size of Debug Information
 -------------------------------------
 
@@ -1178,30 +1238,40 @@ Microsoft extensions
 --------------------
 
 clang has some experimental support for extensions from Microsoft Visual
-C++; to enable it, use the -fms-extensions command-line option. This is
-the default for Windows targets. Note that the support is incomplete;
-enabling Microsoft extensions will silently drop certain constructs
-(including ``__declspec`` and Microsoft-style asm statements).
+C++; to enable it, use the ``-fms-extensions`` command-line option. This is
+the default for Windows targets. Note that the support is incomplete.
+Some constructs such as ``dllexport`` on classes are ignored with a warning,
+and others such as `Microsoft IDL annotations
+`_ are silently
+ignored.
 
-clang has a -fms-compatibility flag that makes clang accept enough
-invalid C++ to be able to parse most Microsoft headers. This flag is
-enabled by default for Windows targets.
+clang has a ``-fms-compatibility`` flag that makes clang accept enough
+invalid C++ to be able to parse most Microsoft headers. For example, it
+allows `unqualified lookup of dependent base class members
+`_, which is
+a common compatibility issue with clang. This flag is enabled by default
+for Windows targets.
 
--fdelayed-template-parsing lets clang delay all template instantiation
-until the end of a translation unit. This flag is enabled by default for
-Windows targets.
+``-fdelayed-template-parsing`` lets clang delay parsing of function template
+definitions until the end of a translation unit. This flag is enabled by
+default for Windows targets.
 
 -  clang allows setting ``_MSC_VER`` with ``-fmsc-version=``. It defaults to
-   1300 which is the same as Visual C/C++ 2003. Any number is supported
+   1700 which is the same as Visual C/C++ 2012. Any number is supported
    and can greatly affect what Windows SDK and c++stdlib headers clang
-   can compile. This option will be removed when clang supports the full
-   set of MS extensions required for these headers.
+   can compile.
 -  clang does not support the Microsoft extension where anonymous record
    members can be declared using user defined typedefs.
--  clang supports the Microsoft "#pragma pack" feature for controlling
+-  clang supports the Microsoft ``#pragma pack`` feature for controlling
    record layout. GCC also contains support for this feature, however
    where MSVC and GCC are incompatible clang follows the MSVC
    definition.
+-  clang supports the Microsoft ``#pragma comment(lib, "foo.lib")`` feature for
+   automatically linking against the specified library.  Currently this feature
+   only works with the Visual C++ linker.
+-  clang supports the Microsoft ``#pragma comment(linker, "/flag:foo")`` feature
+   for adding linker flags to COFF object files.  The user is responsible for
+   ensuring that the linker understands the flags.
 -  clang defaults to C++11 for Windows targets.
 
 .. _cxx:
@@ -1210,8 +1280,8 @@ C++ Language Features
 =====================
 
 clang fully implements all of standard C++98 except for exported
-templates (which were removed in C++11), and `many C++11
-features `_ are also implemented.
+templates (which were removed in C++11), and all of standard C++11
+and the current draft standard for C++1y.
 
 Controlling implementation limits
 ---------------------------------
@@ -1229,7 +1299,12 @@ Controlling implementation limits
 .. option:: -ftemplate-depth=N
 
   Sets the limit for recursively nested template instantiations to N.  The
-  default is 1024.
+  default is 256.
+
+.. option:: -foperator-arrow-depth=N
+
+  Sets the limit for iterative calls to 'operator->' functions to N.  The
+  default is 256.
 
 .. _objc:
 
@@ -1258,8 +1333,8 @@ Darwin (Mac OS/X), Linux, FreeBSD, and Dragonfly BSD: it has been tested
 to correctly compile many large C, C++, Objective-C, and Objective-C++
 codebases.
 
-On ``x86_64-mingw32``, passing i128(by value) is incompatible to Microsoft
-x64 calling conversion. You might need to tweak
+On ``x86_64-mingw32``, passing i128(by value) is incompatible with the
+Microsoft x64 calling conversion. You might need to tweak
 ``WinX86_64ABIInfo::classify()`` in lib/CodeGen/TargetInfo.cpp.
 
 ARM
@@ -1271,11 +1346,19 @@ C++, Objective-C, and Objective-C++ codebases. Clang only supports a
 limited number of ARM architectures. It does not yet fully support
 ARMv5, for example.
 
+PowerPC
+^^^^^^^
+
+The support for PowerPC (especially PowerPC64) is considered stable
+on Linux and FreeBSD: it has been tested to correctly compile many
+large C and C++ codebases. PowerPC (32bit) is still missing certain
+features (e.g. PIC code on ELF platforms).
+
 Other platforms
 ^^^^^^^^^^^^^^^
 
-clang currently contains some support for PPC and Sparc; however,
-significant pieces of code generation are still missing, and they
+clang currently contains some support for other architectures (e.g. Sparc);
+however, significant pieces of code generation are still missing, and they
 haven't undergone significant testing.
 
 clang contains limited support for the MSP430 embedded processor, but
@@ -1302,9 +1385,10 @@ None
 Windows
 ^^^^^^^
 
-Experimental supports are on Cygming.
+Clang has experimental support for targeting "Cygming" (Cygwin / MinGW)
+platforms.
 
-See also `Microsoft Extensions `.
+See also :ref:`Microsoft Extensions `.
 
 Cygwin
 """"""
@@ -1349,3 +1433,111 @@ Clang expects the GCC executable "gcc.exe" compiled for
 
 `Some tests might fail `_ on
 ``x86_64-w64-mingw32``.
+
+.. _clang-cl:
+
+clang-cl
+========
+
+clang-cl is an alternative command-line interface to Clang driver, designed for
+compatibility with the Visual C++ compiler, cl.exe.
+
+To enable clang-cl to find system headers, libraries, and the linker when run
+from the command-line, it should be executed inside a Visual Studio Native Tools
+Command Prompt or a regular Command Prompt where the environment has been set
+up using e.g. `vcvars32.bat `_.
+
+clang-cl can also be used from inside Visual Studio  by using an LLVM Platform
+Toolset.
+
+Command-Line Options
+--------------------
+
+To be compatible with cl.exe, clang-cl supports most of the same command-line
+options. Those options can start with either ``/`` or ``-``. It also supports
+some of Clang's core options, such as the ``-W`` options.
+
+Options that are known to clang-cl, but not currently supported, are ignored
+with a warning. For example:
+
+  ::
+
+    clang-cl.exe: warning: argument unused during compilation: '/Zi'
+
+To suppress warnings about unused arguments, use the ``-Qunused-arguments`` option.
+
+Options that are not known to clang-cl will cause errors. If they are spelled with a
+leading ``/``, they will be mistaken for a filename:
+
+  ::
+
+    clang-cl.exe: error: no such file or directory: '/foobar'
+
+Please `file a bug `_
+for any valid cl.exe flags that clang-cl does not understand.
+
+Execute ``clang-cl /?`` to see a list of supported options:
+
+  ::
+
+    /?                     Display available options
+    /c                     Compile only
+    /D      Define macro
+    /fallback              Fall back to cl.exe if clang-cl fails to compile
+    /FA                    Output assembly code file during compilation
+    /Fa Output assembly code to this file during compilation
+    /Fe Set output executable file or directory (ends in / or \)
+    /FI             Include file before parsing
+    /Fo Set output object file, or directory (ends in / or \)
+    /GF-                   Disable string pooling
+    /GR-                   Disable RTTI
+    /GR                    Enable RTTI
+    /help                  Display available options
+    /I                Add directory to include search path
+    /J                     Make char type unsigned
+    /LDd                   Create debug DLL
+    /LD                    Create DLL
+    /link         Forward options to the linker
+    /MDd                   Use DLL debug run-time
+    /MD                    Use DLL run-time
+    /MTd                   Use static debug run-time
+    /MT                    Use static run-time
+    /Ob0                   Disable inlining
+    /Od                    Disable optimization
+    /Oi-                   Disable use of builtin functions
+    /Oi                    Enable use of builtin functions
+    /Os                    Optimize for size
+    /Ot                    Optimize for speed
+    /Ox                    Maximum optimization
+    /Oy-                   Disable frame pointer omission
+    /Oy                    Enable frame pointer omission
+    /O                  Optimization level
+    /P                     Only run the preprocessor
+    /showIncludes          Print info about included files to stderr
+    /TC                    Treat all source files as C
+    /Tc          Specify a C source file
+    /TP                    Treat all source files as C++
+    /Tp          Specify a C++ source file
+    /U              Undefine macro
+    /W0                    Disable all warnings
+    /W1                    Enable -Wall
+    /W2                    Enable -Wall
+    /W3                    Enable -Wall
+    /W4                    Enable -Wall
+    /Wall                  Enable -Wall
+    /WX-                   Do not treat warnings as errors
+    /WX                    Treat warnings as errors
+    /w                     Disable all warnings
+    /Zs                    Syntax-check only
+
+The /fallback Option
+^^^^^^^^^^^^^^^^^^^^
+
+When clang-cl is run with the ``/fallback`` option, it will first try to
+compile files itself. For any file that it fails to compile, it will fall back
+and try to compile the file by invoking cl.exe.
+
+This option is intended to be used as a temporary means to build projects where
+clang-cl cannot successfully compile all the files. clang-cl may fail to compile
+a file either because it cannot generate code for some C++ feature, or because
+it cannot parse some Microsoft language extension.
diff --git a/docs/analyzer/DebugChecks.rst b/docs/analyzer/DebugChecks.rst
index f8e6f827c1be..14d6ae4c4c91 100644
--- a/docs/analyzer/DebugChecks.rst
+++ b/docs/analyzer/DebugChecks.rst
@@ -30,6 +30,10 @@ using a 'dot' format viewer (such as Graphviz on OS X) instead.
 - debug.DumpLiveVars: Show the results of live variable analysis for each
   top-level function being analyzed.
 
+- debug.ViewExplodedGraph: Show the Exploded Graphs generated for the
+  analysis of different functions in the input translation unit. When there
+  are several functions analyzed, display one graph per function. Beware 
+  that these graphs may grow very large, even for small functions.
 
 Path Tracking
 =============
@@ -121,6 +125,19 @@ ExprInspection checks
       clang_analyzer_eval(value == 42); // expected-warning{{TRUE}}
     }
 
+- void clang_analyzer_warnIfReached();
+
+  Generate a warning if this line of code gets reached by the analyzer.
+
+  Example usage::
+
+    if (true) {
+      clang_analyzer_warnIfReached();  // expected-warning{{REACHABLE}}
+    }
+    else {
+      clang_analyzer_warnIfReached();  // no-warning
+    }
+
 
 Statistics
 ==========
diff --git a/docs/analyzer/IPA.txt b/docs/analyzer/IPA.txt
index 01e73cec7ff0..14da71e09030 100644
--- a/docs/analyzer/IPA.txt
+++ b/docs/analyzer/IPA.txt
@@ -74,7 +74,7 @@ This option controls whether functions from the C++ standard library, including
 methods of the container classes in the Standard Template Library, should be
 considered for inlining.
 
-    -analyzer-config c++-template-inlining=[true | false]
+    -analyzer-config c++-stdlib-inlining=[true | false]
 
 Currently, C++ standard library functions are considered for inlining by 
 default.
diff --git a/docs/analyzer/conf.py b/docs/analyzer/conf.py
index dff9610ac650..3690f936d336 100644
--- a/docs/analyzer/conf.py
+++ b/docs/analyzer/conf.py
@@ -48,9 +48,9 @@
 # built documents.
 #
 # The short X.Y version.
-version = '3.3'
+version = '3.4'
 # The full version, including alpha/beta/rc tags.
-release = '3.3'
+release = '3.4'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
diff --git a/docs/conf.py b/docs/conf.py
index 92741d25917c..183a285de249 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -48,9 +48,9 @@
 # built documents.
 #
 # The short X.Y version.
-version = '3.3'
+version = '3.4'
 # The full version, including alpha/beta/rc tags.
-release = '3.3'
+release = '3.4'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
diff --git a/docs/doxygen.cfg.in b/docs/doxygen.cfg.in
index ed9ffcb85a53..61c0bd847f8a 100644
--- a/docs/doxygen.cfg.in
+++ b/docs/doxygen.cfg.in
@@ -1224,7 +1224,30 @@ DOT_CLEANUP            = YES
 # Configuration::additions related to the search engine   
 #---------------------------------------------------------------------------
 
-# The SEARCHENGINE tag specifies whether or not a search engine should be 
-# used. If set to NO the values of all tags below this one will be ignored.
+# When the SEARCHENGINE tag is enabled doxygen will generate a search box
+# for the HTML output. The underlying search engine uses javascript
+# and DHTML and should work on any modern browser. Note that when using
+# HTML help (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets
+# (GENERATE_DOCSET) there is already a search function so this one should
+# typically be disabled. For large projects the javascript based search engine
+# can be slow, then enabling SERVER_BASED_SEARCH may provide a better solution.
 
-SEARCHENGINE           = NO
+SEARCHENGINE           = @enable_searchengine@
+
+# When the SERVER_BASED_SEARCH tag is enabled the search engine will be
+# implemented using a PHP enabled web server instead of at the web client
+# using Javascript. Doxygen will generate the search PHP script and index
+# file to put on the web server. The advantage of the server
+# based approach is that it scales better to large projects and allows
+# full text search. The disadvances is that it is more difficult to setup
+# and does not have live searching capabilities.
+
+SERVER_BASED_SEARCH    = @enable_server_based_search@
+
+SEARCHENGINE_URL       = @searchengine_url@
+
+EXTERNAL_SEARCH        = @enable_external_search@
+
+EXTERNAL_SEARCH_ID     = clang
+
+EXTRA_SEARCH_MAPPINGS  = @extra_search_mappings@
diff --git a/docs/doxygen.footer b/docs/doxygen.footer
index 524e9a2bb8b9..02db39fa559e 100644
--- a/docs/doxygen.footer
+++ b/docs/doxygen.footer
@@ -1,6 +1,6 @@