llvm-project/clang
Richard Smith 85567ddaba [modules] Fix crash in complex class merging scenario.
When we merge together class definitions, we can end up with the canonical
declaration of a field not being the one that was lexically within the
canonical definition of the class. Additionally, when we merge class
definitions via update records (eg, for a template specialization whose
declaration is instantiated in one module and whose definition is instantiated
in multiple others), we can end up with the list of lexical contents for the
class not including a particular declaration of a field whose lexical parent is
that class definition. In the worst case, we have a field whose canonical
declaration's lexical parent has no fields, and in that case this attempt to
number the fields by walking the fields in the declaration of the class that
contained one of the canonical fields will fail.

Instead, when numbering fields in a class, do the obvious thing: walk the
fields in the definition.

I'm still trying to reduce a testcase; the setup that leads to the above
scenario seems to be quite fragile.

llvm-svn: 318245
2017-11-15 01:33:46 +00:00
..
INPUTS
bindings [python] [tests] Fix test_linkage for unique external linkage 2017-11-11 20:01:41 +00:00
cmake [clang-fuzzer] Fix incremental builds of the fuzzer 2017-10-31 20:49:57 +00:00
docs Make isDefinition matcher support ObjCMethodDecl 2017-11-14 14:17:26 +00:00
examples
include [AST] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). 2017-11-14 23:35:42 +00:00
lib [modules] Fix crash in complex class merging scenario. 2017-11-15 01:33:46 +00:00
runtime Allow building libFuzzer tests in two-stage compiler-rt build. 2017-10-13 23:50:53 +00:00
test [PGO] Detect more structural changes with the stable hash 2017-11-14 23:56:53 +00:00
tools [libclang] Allow crash recovery with LIBCLANG_NOTHREADS 2017-11-14 09:34:39 +00:00
unittests [refactor][selection] canonicalize decl ref callee to the call expr 2017-11-14 23:10:50 +00:00
utils Move the clang-tblgen project into the Clang tablegenning folder on IDEs like Visual Studio rather than leave it in the root directory. NFC. 2017-11-04 20:06:22 +00:00
www Update link to the Chromium Clang page 2017-11-13 23:27:53 +00:00
.arcconfig
.clang-format
.clang-tidy
.gitignore
CMakeLists.txt Add CLANG_DEFAULT_OBJCOPY to allow Clang to use llvm-objcopy for dwarf fission 2017-11-11 01:15:41 +00:00
CODE_OWNERS.TXT
INSTALL.txt
LICENSE.TXT
ModuleInfo.txt
NOTES.txt
README.txt Test commit 2017-10-21 16:03:17 +00:00

README.txt

//===----------------------------------------------------------------------===//
// C Language Family Front-end
//===----------------------------------------------------------------------===//

Welcome to Clang.  This is a compiler front-end for the C family of languages
(C, C++, Objective-C, and Objective-C++) which is built as part of the LLVM
compiler infrastructure project.

Unlike many other compiler frontends, Clang is useful for a number of things
beyond just compiling code: we intend for Clang to be host to a number of
different source-level tools.  One example of this is the Clang Static Analyzer.

If you're interested in more (including how to build Clang) it is best to read
the relevant web sites.  Here are some pointers:

Information on Clang:             http://clang.llvm.org/
Building and using Clang:         http://clang.llvm.org/get_started.html
Clang Static Analyzer:            http://clang-analyzer.llvm.org/
Information on the LLVM project:  http://llvm.org/

If you have questions or comments about Clang, a great place to discuss them is
on the Clang development mailing list:
  http://lists.llvm.org/mailman/listinfo/cfe-dev

If you find a bug in Clang, please file it in the LLVM bug tracker:
  http://llvm.org/bugs/