Go to file

Haojian Wu 733edf9750 [AST] Add RecoveryExpr to retain expressions on semantic errors Normally clang avoids creating expressions when it encounters semantic errors, even if the parser knows which expression to produce. This works well for the compiler. However, this is not ideal for source-level tools that have to deal with broken code, e.g. clangd is not able to provide navigation features even for names that compiler knows how to resolve. The new RecoveryExpr aims to capture the minimal set of information useful for the tools that need to deal with incorrect code: source range of the expression being dropped, subexpressions of the expression. We aim to make constructing RecoveryExprs as simple as possible to ensure writing code to avoid dropping expressions is easy. Producing RecoveryExprs can result in new code paths being taken in the frontend. In particular, clang can produce some new diagnostics now and we aim to suppress bogus ones based on Expr::containsErrors. We deliberately produce RecoveryExprs only in the parser for now to minimize the code affected by this patch. Producing RecoveryExprs in Sema potentially allows to preserve more information (e.g. type of an expression), but also results in more code being affected. E.g. SFINAE checks will have to take presence of RecoveryExprs into account. Initial implementation only works in C++ mode, as it relies on compiler postponing diagnostics on dependent expressions. C and ObjC often do not do this, so they require more work to make sure we do not produce too many bogus diagnostics on the new expressions. See documentation of RecoveryExpr for more details. original patch from Ilya This change is based on https://reviews.llvm.org/D61722 Reviewers: sammccall, rsmith Reviewed By: sammccall, rsmith Tags: #clang Differential Revision: https://reviews.llvm.org/D69330		2020-03-24 09:20:37 +01:00
clang	[AST] Add RecoveryExpr to retain expressions on semantic errors	2020-03-24 09:20:37 +01:00
clang-tools-extra	[clangd] Rename theia-derived semantic highlighting protocol. NFC	2020-03-24 00:39:47 +01:00
compiler-rt	scudo: Create a public include directory. NFCI.	2020-03-23 18:23:29 -07:00
debuginfo-tests	[DexTer] Add step.UNKNOWN check for NoneType line numbers.	2020-03-16 16:38:41 +00:00
libc	[libc] Enable llvmlibc clang-tidy checks	2020-03-23 20:34:39 -07:00
libclc	libclc: cmake configure should depend on file list	2020-02-25 04:43:14 -05:00
libcxx	[libc++] Bump Clang support for Clang 4	2020-03-23 12:17:04 -04:00
libcxxabi	Revert "Remove legacy CMake targets for libcxx and libcxxabi"	2020-03-23 11:03:00 -04:00
libunwind	Doc: Links should use https	2020-03-22 22:49:33 +01:00
lld	[lld] Enabling loading LLVM pass plugins	2020-03-23 14:18:32 -07:00
lldb	[lldb-vscode] Add missing launchCommands entry in the package.json	2020-03-23 23:21:30 -07:00
llvm	[PowerPC] fix a typo in commit `3f85134d71`	2020-03-24 01:56:15 -04:00
mlir	[MLIR][NFC] flat affine constraints - refactor to share, renames	2020-03-24 10:57:42 +05:30
openmp	[openmp][runtime] Fixed hang for explicit task inside a taskloop.	2020-03-23 20:07:30 +03:00
parallel-libs	[arcconfig] Delete subproject arcconfigs	2020-02-24 16:20:36 -08:00
polly	Doc: Links should use https	2020-03-22 22:49:33 +01:00
pstl	[pstl] A hot fix for exclusive_scan (+ lost enable_if in declaration)	2020-03-17 16:22:24 -04:00
.arcconfig	[arcconfig] Default base to previous revision	2020-02-24 16:20:25 -08:00
.clang-format	…
.clang-tidy	- Update .clang-tidy to ignore parameters of main like functions for naming violations in clang and llvm directory	2020-01-31 16:49:45 +00:00
.git-blame-ignore-revs	Add some libc++ revisions to .git-blame-ignore-revs	2020-03-17 17:30:20 -04:00
.gitignore	Add a newline at the end of the file	2019-09-04 06:33:46 +00:00
CONTRIBUTING.md	Add contributing info to CONTRIBUTING.md and README.md	2019-12-02 15:47:15 +00:00
README.md	[README] Add note on using cmake to perform the build	2020-02-12 14:51:24 -06:00

README.md

The LLVM Compiler Infrastructure

This directory and its sub-directories contain source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.

The README briefly describes how to get started with building LLVM. For more information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.

Getting Started with the LLVM System

Taken from https://llvm.org/docs/GettingStarted.html.

Overview

Welcome to the LLVM project!

The LLVM project has multiple components. The core of the project is itself called "LLVM". This contains all of the tools, libraries, and header files needed to process intermediate representations and converts it into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer. It also contains basic regression tests.

C-like languages use the Clang front end. This component compiles C, C++, Objective C, and Objective C++ code into LLVM bitcode -- and from there into object files, using LLVM.

Other components include: the libc++ C++ standard library, the LLD linker, and more.

Getting the Source Code and Building LLVM

The LLVM Getting Started documentation may be out of date. The Clang Getting Started page might have more accurate information.

This is an example work-flow and configuration to get and build the LLVM source:

Checkout LLVM (including related sub-projects like Clang):
- git clone https://github.com/llvm/llvm-project.git
- Or, on windows, git clone --config core.autocrlf=false https://github.com/llvm/llvm-project.git
Configure and build LLVM and Clang:
- cd llvm-project
- mkdir build
- cd build
- cmake -G <generator> [options] ../llvm
  
  Some common build system generators are:
  - Ninja --- for generating Ninja build files. Most llvm developers use Ninja.
  - Unix Makefiles --- for generating make-compatible parallel makefiles.
  - Visual Studio --- for generating Visual Studio projects and solutions.
  - Xcode --- for generating Xcode projects.
  Some Common options:
  - -DLLVM_ENABLE_PROJECTS='...' --- semicolon-separated list of the LLVM sub-projects you'd like to additionally build. Can include any of: clang, clang-tools-extra, libcxx, libcxxabi, libunwind, lldb, compiler-rt, lld, polly, or debuginfo-tests.
    
    For example, to build LLVM, Clang, libcxx, and libcxxabi, use -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi".
  - -DCMAKE_INSTALL_PREFIX=directory --- Specify for directory the full path name of where you want the LLVM tools and libraries to be installed (default /usr/local).
  - -DCMAKE_BUILD_TYPE=type --- Valid options for type are Debug, Release, RelWithDebInfo, and MinSizeRel. Default is Debug.
  - -DLLVM_ENABLE_ASSERTIONS=On --- Compile with assertion checks enabled (default is Yes for Debug builds, No for all other build types).
- cmake --build . [-- [options] <target>] or your build system specified above directly.
  - The default target (i.e. ninja or make) will build all of LLVM.
  - The check-all target (i.e. ninja check-all) will run the regression tests to ensure everything is in working order.
  - CMake will generate targets for each tool and library, and most LLVM sub-projects generate their own check-<project> target.
  - Running a serial build will be slow. To improve speed, try running a parallel build. That's done by default in Ninja; for make, use the option -j NNN, where NNN is the number of parallel jobs, e.g. the number of CPUs you have.
- For more information see CMake

Consult the Getting Started with LLVM page for detailed information on configuring and compiling LLVM. You can visit Directory Layout to learn about the layout of the source code tree.