summaryrefslogtreecommitdiffstats
path: root/clang/docs
Commit message (Collapse)AuthorAgeFilesLines
...
* [Support] Fix `-ftime-trace-granularity` optionAnton Afanasyev2019-07-241-0/+8
| | | | | | | | | | | | | | | | Summary: Move `-ftime-trace-granularity` option to frontend options. Without patch this option is showed up in the help for any tool that links libSupport. Reviewers: sammccall Subscribers: hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65202 llvm-svn: 366911
* [analyzer] Add CTU user docsGabor Marton2019-07-182-0/+207
| | | | | | | | | | | | Reviewers: dkrupp, a_sidorin, Szelethus, NoQ Subscribers: whisperity, xazax.hun, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, gamesh411, Charusso, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64801 llvm-svn: 366439
* Bump the trunk version to 10.0.0svnHans Wennborg2019-07-182-53/+18
| | | | | | and clear the release notes. llvm-svn: 366427
* [Docs][OpenCL] Documentation of C++ for OpenCL modeAnastasia Stulova2019-07-172-1/+310
| | | | | | | | | Added documentation of C++ for OpenCL mode into Clang User Manual and Language Extensions document. Differential Revision: https://reviews.llvm.org/D64418 llvm-svn: 366351
* Finish "Adapt -fsanitize=function to SANITIZER_NON_UNIQUE_TYPEINFO"Stephan Bergmann2019-07-161-2/+2
| | | | | | | | | | | | | | | | | | | | | i.e., recent 5745eccef54ddd3caca278d1d292a88b2281528b: * Bump the function_type_mismatch handler version, as its signature has changed. * The function_type_mismatch handler can return successfully now, so SanitizerKind::Function must be AlwaysRecoverable (like for SanitizerKind::Vptr). * But the minimal runtime would still unconditionally treat a call to the function_type_mismatch handler as failure, so disallow -fsanitize=function in combination with -fsanitize-minimal-runtime (like it was already done for -fsanitize=vptr). * Add tests. Differential Revision: https://reviews.llvm.org/D61479 llvm-svn: 366186
* Update __VERSION__ to remove the hardcoded 4.2.1 versionSylvestre Ledru2019-07-152-0/+8
| | | | | | | | | | | | | | | | | | Summary: Just like in https://reviews.llvm.org/D56803 for -dumpversion Reviewers: rnk Reviewed By: rnk Subscribers: dexonsmith, lebedev.ri, hubert.reinterpretcast, xbolva00, fedor.sergeev, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63048 llvm-svn: 366091
* Support __seg_fs and __seg_gs on x86JF Bastien2019-07-141-0/+4
| | | | | | | | | | | | | | | | | | | | | Summary: GCC supports named address spaces macros: https://gcc.gnu.org/onlinedocs/gcc/Named-Address-Spaces.html clang does as well with address spaces: https://clang.llvm.org/docs/LanguageExtensions.html#memory-references-to-specified-segments Add the __seg_fs and __seg_gs macros for compatibility with GCC. <rdar://problem/52944935> Subscribers: jkorous, dexonsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64676 llvm-svn: 366028
* consistency in the release notesSylvestre Ledru2019-07-141-2/+2
| | | | llvm-svn: 366024
* This reverts commit 632a36bfcfc8273c1861f04ff6758d863c47c784.Sylvestre Ledru2019-07-132-12/+0
| | | | | | | | | | | | Some targets such as Python 2.7.16 still use VERSION in their builds. Without VERSION defined, the source code has syntax errors. Reverting as it will probably break many other things. Noticed by Sterling Augustine llvm-svn: 365992
* Remove __VERSION__Sylvestre Ledru2019-07-122-0/+12
| | | | | | | | | | | | | | | | | | | | Summary: It has been introduced in 2011 for gcc compat: https://github.com/llvm-mirror/clang/commit/ad1a4c6e89594e704775ddb6b036ac982fd68cad it is probably time to remove it Reviewers: rnk, dexonsmith Reviewed By: rnk Subscribers: dschuff, aheejin, fedor.sergeev, arphaman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64062 llvm-svn: 365962
* [Driver] -noprofilelib flagPetr Hosek2019-07-111-0/+2
| | | | | | | | | | This flag is analoguous to other flags like -nostdlib or -nolibc and could be used to disable linking of profile runtime library. This is useful in certain environments like kernel, where profile instrumentation is still desirable, but we cannot use the standard runtime library. llvm-svn: 365808
* [Docs] Add standardized header links to analyzer docNathan Huckleberry2019-07-111-0/+268
| | | | | | | | | | | | | | | | | | | | | | | Summary: Header links should have some standard form so clang tidy docs can easily reference them. The form is as follows. Start with the analyzer full name including packages. Replace all periods with dashes and lowercase everything. Ex: core.CallAndMessage -> core-callandmessage Reviewers: JonasToth, aaron.ballman, NoQ, Szelethus Reviewed By: aaron.ballman, Szelethus Subscribers: nickdesaulniers, lebedev.ri, baloghadamsoftware, mgrang, a.sidorin, Szelethus, jfb, donat.nagy, dkrupp, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64543 llvm-svn: 365797
* [analyzer]Add user docs rstGabor Marton2019-07-102-3/+8
| | | | | | | | | | | | | | | | Summary: Add user documentation page. This is an empty page atm, later patches will add the specific user documentatoins. Reviewers: dkrupp Subscribers: whisperity, xazax.hun, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, gamesh411, Charusso, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64494 llvm-svn: 365639
* hwasan: Improve precision of checks using short granule tags.Peter Collingbourne2019-07-091-12/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A short granule is a granule of size between 1 and `TG-1` bytes. The size of a short granule is stored at the location in shadow memory where the granule's tag is normally stored, while the granule's actual tag is stored in the last byte of the granule. This means that in order to verify that a pointer tag matches a memory tag, HWASAN must check for two possibilities: * the pointer tag is equal to the memory tag in shadow memory, or * the shadow memory tag is actually a short granule size, the value being loaded is in bounds of the granule and the pointer tag is equal to the last byte of the granule. Pointer tags between 1 to `TG-1` are possible and are as likely as any other tag. This means that these tags in memory have two interpretations: the full tag interpretation (where the pointer tag is between 1 and `TG-1` and the last byte of the granule is ordinary data) and the short tag interpretation (where the pointer tag is stored in the granule). When HWASAN detects an error near a memory tag between 1 and `TG-1`, it will show both the memory tag and the last byte of the granule. Currently, it is up to the user to disambiguate the two possibilities. Because this functionality obsoletes the right aligned heap feature of the HWASAN memory allocator (and because we can no longer easily test it), the feature is removed. Also update the documentation to cover both short granule tags and outlined checks. Differential Revision: https://reviews.llvm.org/D63908 llvm-svn: 365551
* Remove trailing whitespaces in the Language Extensions docSylvestre Ledru2019-07-091-13/+13
| | | | llvm-svn: 365446
* Add AlignConsecutiveMacros to the clang release notesSylvestre Ledru2019-07-091-0/+2
| | | | llvm-svn: 365445
* [BPF] Preserve debuginfo array/union/struct type/access indexYonghong Song2019-07-091-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For background of BPF CO-RE project, please refer to http://vger.kernel.org/bpfconf2019.html In summary, BPF CO-RE intends to compile bpf programs adjustable on struct/union layout change so the same program can run on multiple kernels with adjustment before loading based on native kernel structures. In order to do this, we need keep track of GEP(getelementptr) instruction base and result debuginfo types, so we can adjust on the host based on kernel BTF info. Capturing such information as an IR optimization is hard as various optimization may have tweaked GEP and also union is replaced by structure it is impossible to track fieldindex for union member accesses. Three intrinsic functions, preserve_{array,union,struct}_access_index, are introducted. addr = preserve_array_access_index(base, index, dimension) addr = preserve_union_access_index(base, di_index) addr = preserve_struct_access_index(base, gep_index, di_index) here, base: the base pointer for the array/union/struct access. index: the last access index for array, the same for IR/DebugInfo layout. dimension: the array dimension. gep_index: the access index based on IR layout. di_index: the access index based on user/debuginfo types. If using these intrinsics blindly, i.e., transforming all GEPs to these intrinsics and later on reducing them to GEPs, we have seen up to 7% more instructions generated. To avoid such an overhead, a clang builtin is proposed: base = __builtin_preserve_access_index(base) such that user wraps to-be-relocated GEPs in this builtin and preserve_*_access_index intrinsics only apply to those GEPs. Such a buyin will prevent performance degradation if people do not use CO-RE, even for programs which use bpf_probe_read(). For example, for the following example, $ cat test.c struct sk_buff { int i; int b1:1; int b2:2; union { struct { int o1; int o2; } o; struct { char flags; char dev_id; } dev; int netid; } u[10]; }; static int (*bpf_probe_read)(void *dst, int size, const void *unsafe_ptr) = (void *) 4; #define _(x) (__builtin_preserve_access_index(x)) int bpf_prog(struct sk_buff *ctx) { char dev_id; bpf_probe_read(&dev_id, sizeof(char), _(&ctx->u[5].dev.dev_id)); return dev_id; } $ clang -target bpf -O2 -g -emit-llvm -S -mllvm -print-before-all \ test.c >& log The generated IR looks like below: ... define dso_local i32 @bpf_prog(%struct.sk_buff*) #0 !dbg !15 { %2 = alloca %struct.sk_buff*, align 8 %3 = alloca i8, align 1 store %struct.sk_buff* %0, %struct.sk_buff** %2, align 8, !tbaa !45 call void @llvm.dbg.declare(metadata %struct.sk_buff** %2, metadata !43, metadata !DIExpression()), !dbg !49 call void @llvm.lifetime.start.p0i8(i64 1, i8* %3) #4, !dbg !50 call void @llvm.dbg.declare(metadata i8* %3, metadata !44, metadata !DIExpression()), !dbg !51 %4 = load i32 (i8*, i32, i8*)*, i32 (i8*, i32, i8*)** @bpf_probe_read, align 8, !dbg !52, !tbaa !45 %5 = load %struct.sk_buff*, %struct.sk_buff** %2, align 8, !dbg !53, !tbaa !45 %6 = call [10 x %union.anon]* @llvm.preserve.struct.access.index.p0a10s_union.anons.p0s_struct.sk_buffs( %struct.sk_buff* %5, i32 2, i32 3), !dbg !53, !llvm.preserve.access.index !19 %7 = call %union.anon* @llvm.preserve.array.access.index.p0s_union.anons.p0a10s_union.anons( [10 x %union.anon]* %6, i32 1, i32 5), !dbg !53 %8 = call %union.anon* @llvm.preserve.union.access.index.p0s_union.anons.p0s_union.anons( %union.anon* %7, i32 1), !dbg !53, !llvm.preserve.access.index !26 %9 = bitcast %union.anon* %8 to %struct.anon.0*, !dbg !53 %10 = call i8* @llvm.preserve.struct.access.index.p0i8.p0s_struct.anon.0s( %struct.anon.0* %9, i32 1, i32 1), !dbg !53, !llvm.preserve.access.index !34 %11 = call i32 %4(i8* %3, i32 1, i8* %10), !dbg !52 %12 = load i8, i8* %3, align 1, !dbg !54, !tbaa !55 %13 = sext i8 %12 to i32, !dbg !54 call void @llvm.lifetime.end.p0i8(i64 1, i8* %3) #4, !dbg !56 ret i32 %13, !dbg !57 } !19 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "sk_buff", file: !3, line: 1, size: 704, elements: !20) !26 = distinct !DICompositeType(tag: DW_TAG_union_type, scope: !19, file: !3, line: 5, size: 64, elements: !27) !34 = distinct !DICompositeType(tag: DW_TAG_structure_type, scope: !26, file: !3, line: 10, size: 16, elements: !35) Note that @llvm.preserve.{struct,union}.access.index calls have metadata llvm.preserve.access.index attached to instructions to provide struct/union debuginfo type information. For &ctx->u[5].dev.dev_id, . The "%6 = ..." represents struct member "u" with index 2 for IR layout and index 3 for DI layout. . The "%7 = ..." represents array subscript "5". . The "%8 = ..." represents union member "dev" with index 1 for DI layout. . The "%10 = ..." represents struct member "dev_id" with index 1 for both IR and DI layout. Basically, traversing the use-def chain recursively for the 3rd argument of bpf_probe_read() and examining all preserve_*_access_index calls, the debuginfo struct/union/array access index can be achieved. The intrinsics also contain enough information to regenerate codes for IR layout. For array and structure intrinsics, the proper GEP can be constructed. For union intrinsics, replacing all uses of "addr" with "base" should be enough. Signed-off-by: Yonghong Song <yhs@fb.com> Differential Revision: https://reviews.llvm.org/D61809 llvm-svn: 365438
* Revert "[BPF] Preserve debuginfo array/union/struct type/access index"Yonghong Song2019-07-091-29/+0
| | | | | | | | | This reverts commit r365435. Forgot adding the Differential Revision link. Will add to the commit message and resubmit. llvm-svn: 365436
* [BPF] Preserve debuginfo array/union/struct type/access indexYonghong Song2019-07-091-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For background of BPF CO-RE project, please refer to http://vger.kernel.org/bpfconf2019.html In summary, BPF CO-RE intends to compile bpf programs adjustable on struct/union layout change so the same program can run on multiple kernels with adjustment before loading based on native kernel structures. In order to do this, we need keep track of GEP(getelementptr) instruction base and result debuginfo types, so we can adjust on the host based on kernel BTF info. Capturing such information as an IR optimization is hard as various optimization may have tweaked GEP and also union is replaced by structure it is impossible to track fieldindex for union member accesses. Three intrinsic functions, preserve_{array,union,struct}_access_index, are introducted. addr = preserve_array_access_index(base, index, dimension) addr = preserve_union_access_index(base, di_index) addr = preserve_struct_access_index(base, gep_index, di_index) here, base: the base pointer for the array/union/struct access. index: the last access index for array, the same for IR/DebugInfo layout. dimension: the array dimension. gep_index: the access index based on IR layout. di_index: the access index based on user/debuginfo types. If using these intrinsics blindly, i.e., transforming all GEPs to these intrinsics and later on reducing them to GEPs, we have seen up to 7% more instructions generated. To avoid such an overhead, a clang builtin is proposed: base = __builtin_preserve_access_index(base) such that user wraps to-be-relocated GEPs in this builtin and preserve_*_access_index intrinsics only apply to those GEPs. Such a buyin will prevent performance degradation if people do not use CO-RE, even for programs which use bpf_probe_read(). For example, for the following example, $ cat test.c struct sk_buff { int i; int b1:1; int b2:2; union { struct { int o1; int o2; } o; struct { char flags; char dev_id; } dev; int netid; } u[10]; }; static int (*bpf_probe_read)(void *dst, int size, const void *unsafe_ptr) = (void *) 4; #define _(x) (__builtin_preserve_access_index(x)) int bpf_prog(struct sk_buff *ctx) { char dev_id; bpf_probe_read(&dev_id, sizeof(char), _(&ctx->u[5].dev.dev_id)); return dev_id; } $ clang -target bpf -O2 -g -emit-llvm -S -mllvm -print-before-all \ test.c >& log The generated IR looks like below: ... define dso_local i32 @bpf_prog(%struct.sk_buff*) #0 !dbg !15 { %2 = alloca %struct.sk_buff*, align 8 %3 = alloca i8, align 1 store %struct.sk_buff* %0, %struct.sk_buff** %2, align 8, !tbaa !45 call void @llvm.dbg.declare(metadata %struct.sk_buff** %2, metadata !43, metadata !DIExpression()), !dbg !49 call void @llvm.lifetime.start.p0i8(i64 1, i8* %3) #4, !dbg !50 call void @llvm.dbg.declare(metadata i8* %3, metadata !44, metadata !DIExpression()), !dbg !51 %4 = load i32 (i8*, i32, i8*)*, i32 (i8*, i32, i8*)** @bpf_probe_read, align 8, !dbg !52, !tbaa !45 %5 = load %struct.sk_buff*, %struct.sk_buff** %2, align 8, !dbg !53, !tbaa !45 %6 = call [10 x %union.anon]* @llvm.preserve.struct.access.index.p0a10s_union.anons.p0s_struct.sk_buffs( %struct.sk_buff* %5, i32 2, i32 3), !dbg !53, !llvm.preserve.access.index !19 %7 = call %union.anon* @llvm.preserve.array.access.index.p0s_union.anons.p0a10s_union.anons( [10 x %union.anon]* %6, i32 1, i32 5), !dbg !53 %8 = call %union.anon* @llvm.preserve.union.access.index.p0s_union.anons.p0s_union.anons( %union.anon* %7, i32 1), !dbg !53, !llvm.preserve.access.index !26 %9 = bitcast %union.anon* %8 to %struct.anon.0*, !dbg !53 %10 = call i8* @llvm.preserve.struct.access.index.p0i8.p0s_struct.anon.0s( %struct.anon.0* %9, i32 1, i32 1), !dbg !53, !llvm.preserve.access.index !34 %11 = call i32 %4(i8* %3, i32 1, i8* %10), !dbg !52 %12 = load i8, i8* %3, align 1, !dbg !54, !tbaa !55 %13 = sext i8 %12 to i32, !dbg !54 call void @llvm.lifetime.end.p0i8(i64 1, i8* %3) #4, !dbg !56 ret i32 %13, !dbg !57 } !19 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "sk_buff", file: !3, line: 1, size: 704, elements: !20) !26 = distinct !DICompositeType(tag: DW_TAG_union_type, scope: !19, file: !3, line: 5, size: 64, elements: !27) !34 = distinct !DICompositeType(tag: DW_TAG_structure_type, scope: !26, file: !3, line: 10, size: 16, elements: !35) Note that @llvm.preserve.{struct,union}.access.index calls have metadata llvm.preserve.access.index attached to instructions to provide struct/union debuginfo type information. For &ctx->u[5].dev.dev_id, . The "%6 = ..." represents struct member "u" with index 2 for IR layout and index 3 for DI layout. . The "%7 = ..." represents array subscript "5". . The "%8 = ..." represents union member "dev" with index 1 for DI layout. . The "%10 = ..." represents struct member "dev_id" with index 1 for both IR and DI layout. Basically, traversing the use-def chain recursively for the 3rd argument of bpf_probe_read() and examining all preserve_*_access_index calls, the debuginfo struct/union/array access index can be achieved. The intrinsics also contain enough information to regenerate codes for IR layout. For array and structure intrinsics, the proper GEP can be constructed. For union intrinsics, replacing all uses of "addr" with "base" should be enough. Signed-off-by: Yonghong Song <yhs@fb.com> llvm-svn: 365435
* Treat the range of representable values of floating-point types as [-inf, ↵Richard Smith2019-07-061-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +inf] not as [-max, +max]. Summary: Prior to r329065, we used [-max, max] as the range of representable values because LLVM's `fptrunc` did not guarantee defined behavior when truncating from a larger floating-point type to a smaller one. Now that has been fixed, we can make clang follow normal IEEE 754 semantics in this regard and take the larger range [-inf, +inf] as the range of representable values. In practice, this affects two parts of the frontend: * the constant evaluator no longer treats floating-point evaluations that result in +-inf as being undefined (because they no longer leave the range of representable values of the type) * UBSan no longer treats conversions to floating-point type that are outside the [-max, +max] range as being undefined In passing, also remove the float-divide-by-zero sanitizer from -fsanitize=undefined, on the basis that while it's undefined per C++ rules (and we disallow it in constant expressions for that reason), it is defined by Clang / LLVM / IEEE 754. Reviewers: rnk, BillyONeal Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63793 llvm-svn: 365272
* clang-format: Add new style option AlignConsecutiveMacrosSam McCall2019-07-021-0/+14
| | | | | | | | | | | | | | | | | | | | | | This option behaves similarly to AlignConsecutiveDeclarations and AlignConsecutiveAssignments, aligning the assignment of C/C++ preprocessor macros on consecutive lines. I've worked in many projects (embedded, mostly) where header files full of large, well-aligned "#define" blocks are a common pattern. We normally avoid using clang-format on these files, since it ruins any existing alignment in said blocks. This style option will align "simple" PP macros (no parameters) and PP macros with parameter lists on consecutive lines. Related Bugzilla entry (thanks mcuddie): https://llvm.org/bugs/show_bug.cgi?id=20637 Patch by Nick Renieris (VelocityRa)! Differential Revision: https://reviews.llvm.org/D28462 llvm-svn: 364938
* print-supported-cpus quality of life patch.Ziang Wan2019-06-252-0/+8
| | | | | | | Claim all input files so that clang does not give a warning. Add two short-cut aliases: -mcpu=? and -mtune=?. llvm-svn: 364362
* [clang] Adapt ASTMatcher to explicit(bool) specifierGauthier Harnisch2019-06-191-6/+79
| | | | | | | | | | | | | | | | | | | | Summary: Changes: - add an ast matcher for deductiong guide. - allow isExplicit matcher for deductiong guide. - add hasExplicitSpecifier matcher which give access to the expression of the explicit specifier if present. Reviewers: klimek, rsmith, aaron.ballman Reviewed By: aaron.ballman Subscribers: aaron.ballman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61552 llvm-svn: 363855
* [Remarks][Driver] Use the specified format in the remarks file extensionFrancis Visoiu Mistrih2019-06-171-1/+3
| | | | | | | By default, use `.opt.yaml`, but when a format is specified with `-fsave-optimization-record=<format>`, use `.opt.<format>`. llvm-svn: 363627
* [Remarks] Extend -fsave-optimization-record to specify the formatFrancis Visoiu Mistrih2019-06-171-5/+13
| | | | | | | | | Use -fsave-optimization-record=<format> to specify a different format than the default, which is YAML. For now, only YAML is supported. llvm-svn: 363573
* [docs] Fix another bot error by setting highlight language of objc ↵Don Hinton2019-06-161-1/+1
| | | | | | code-block to objc instead of c++. llvm-svn: 363521
* Fixed the --print-supported-cpus testZiang Wan2019-06-141-2/+2
| | | | | | | | | | | Add constraints for the test that require specific backend targets to be registered. Remove trailing whitespace in the doc. Differential Revision: https://reviews.llvm.org/D63105 llvm-svn: 363475
* Add --print-supported-cpus flag for clang.Ziang Wan2019-06-142-0/+10
| | | | | | | | | | | | This patch allows clang users to print out a list of supported CPU models using clang [--target=<target triple>] --print-supported-cpus Then, users can select the CPU model to compile to using clang --target=<triple> -mcpu=<model> a.c It is a handy feature to help cross compilation. llvm-svn: 363464
* [Remarks][NFC] Improve testing and documentation of -foptimization-record-passesFrancis Visoiu Mistrih2019-06-141-0/+12
| | | | | | | | | | | This adds: * documentation to the user manual * nicer error message * test for the error case * test for the gold plugin llvm-svn: 363463
* add a missing parenthese in the clang docSylvestre Ledru2019-06-141-1/+1
| | | | llvm-svn: 363369
* [AMDGPU] gfx1010 wave32 clang supportStanislav Mekhanoshin2019-06-131-0/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D63209 llvm-svn: 363341
* Added AST matcher for ignoring elidable constructorsDmitri Gribenko2019-06-131-0/+26
| | | | | | | | | | | | | | | | | | Summary: Added AST matcher for ignoring elidable move constructors Reviewers: hokein, gribozavr Reviewed By: hokein, gribozavr Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D63149 Patch by Johan Vikström. llvm-svn: 363262
* AST Matchers tutorial requests to enable clang-tools-extra. NFCIlya Biryukov2019-06-071-1/+1
| | | | | | Otherwise the examples do not build. llvm-svn: 362812
* clang-format: better handle namespace macrosFrancois Ferrand2019-06-061-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Other macros are used to declare namespaces, and should thus be handled similarly. This is the case for crpcut's TESTSUITE macro, or for unittest-cpp's SUITE macro: TESTSUITE(Foo) { TEST(MyFirstTest) { assert(0); } } // TESTSUITE(Foo) This patch deals with this cases by introducing a new option to specify lists of namespace macros. Internally, it re-uses the system already in place for foreach and statement macros, to ensure there is no impact on performance. Reviewers: krasimir, djasper, klimek Reviewed By: klimek Subscribers: acoomans, cfe-commits, klimek Tags: #clang Differential Revision: https://reviews.llvm.org/D37813 llvm-svn: 362740
* [X86] Add ENQCMD instructionsPengfei Wang2019-06-061-0/+2
| | | | | | | | | | | | For more details about these instructions, please refer to the latest ISE document: https://software.intel.com/en-us/download/intel-architecture-instruction-set-extensions-programming-reference. Patch by Tianqing Wang (tianqing) Differential Revision: https://reviews.llvm.org/D62282 llvm-svn: 362685
* Update AST matchers tutorial to use monorepo layoutIlya Biryukov2019-06-061-6/+6
| | | | | | | | | | The docs were inconsistent: requesting the user to clone the monorepo, and then continuing with the `llvm/tools/clang` layout. Follow-up to a question on cfe-dev: http://lists.llvm.org/pipermail/cfe-dev/2019-June/062518.html llvm-svn: 362683
* [clang-format][NFC] Fix BS_Allman style example in the header docs are ↵Jan Korous2019-06-051-6/+15
| | | | | | | | generated from Differential Revision: https://reviews.llvm.org/D61729 llvm-svn: 362646
* Add __FILE_NAME__ to ReleaseNotes. NFCKristina Brooks2019-06-051-2/+4
| | | | | | | Added it under C language changes as a nonstandard extension for the time being. llvm-svn: 362581
* Add a release note entry for the change made in r362034.Akira Hatanaka2019-06-031-1/+8
| | | | llvm-svn: 362464
* Clarify when fix-it hints on warnings are appropriateAaron Puchert2019-05-311-0/+3
| | | | | | | | | | | | | | | | | | | | | Summary: This is not a change in the rules, it's meant as a clarification about warnings. Since the recovery from warnings is a no-op, the fix-it hints on warnings shouldn't change anything. Anything that doesn't just suppress the warning and changes the meaning of the code (even if it's for the better) should be on an additional note. Reviewers: rsmith, aaron.ballman Reviewed By: aaron.ballman Subscribers: cfe-commits, thakis Tags: #clang Differential Revision: https://reviews.llvm.org/D62470 llvm-svn: 362266
* [X86] Add VP2INTERSECT instructionsPengfei Wang2019-05-311-0/+2
| | | | | | | | | | Support intel AVX512 VP2INTERSECT instructions in clang Patch by Xiang Zhang (xiangzhangllvm) Differential Revision: https://reviews.llvm.org/D62367 llvm-svn: 362196
* [Docs] Modernize references to macOSJ. Ryan Stinnett2019-05-3011-17/+17
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This updates all places in documentation that refer to "Mac OS X", "OS X", etc. to instead use the modern name "macOS" when no specific version number is mentioned. If a specific version is mentioned, this attempts to use the OS name at the time of that version: * Mac OS X for 10.0 - 10.7 * OS X for 10.8 - 10.11 * macOS for 10.12 - present Reviewers: JDevlieghere Subscribers: mgorny, christof, arphaman, cfe-commits, lldb-commits, libcxx-commits, llvm-commits Tags: #clang, #lldb, #libc, #llvm Differential Revision: https://reviews.llvm.org/D62654 llvm-svn: 362113
* [clang-format] Allow configuring list of function-like macros that resolve ↵Francois Ferrand2019-05-291-0/+18
| | | | | | | | | | | | | | | | | | | | | | | to a type Summary: Adds a `TypenameMacros` configuration option that causes certain identifiers to be handled in a way similar to `typeof()`. This is enough to: - Prevent misinterpreting declarations of pointers to such types as expressions (`STACK_OF(int) * foo` -> `STACK_OF(int) *foo`), - Avoid surprising line breaks in variable/struct field declarations (`STACK_OF(int)\nfoo;` -> `STACK_OF(int) foo;`, see https://bugs.llvm.org/show_bug.cgi?id=30353). Reviewers: Typz, krasimir, djasper Reviewed By: Typz Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57184 llvm-svn: 361986
* Driver: support `/Zc:char8_t` and `/Zc:char8_t-`Saleem Abdulrasool2019-05-281-0/+2
| | | | | | | Update the `cl` emulation to support the `/Zc:char8_t[-]?` options as per the MSVC 2019.1 toolset. These are aliases for `-fchar8_t` and `-fno-char8_t`. llvm-svn: 361859
* Add release note entries for recent typo correction changesNico Weber2019-05-281-2/+5
| | | | | | Differential Revision: https://reviews.llvm.org/D62523 llvm-svn: 361824
* [Analyzer] Checker for non-determinism caused by iteration of unordered ↵Mandeep Singh Grang2019-05-241-2/+16
| | | | | | | | | | | | | | | | | | container of pointers Summary: Added a checker for non-determinism caused by iterating unordered containers like std::unordered_set containing pointer elements. Reviewers: NoQ, george.karpenkov, whisperity, Szelethus, baloghadamsoftware Reviewed By: Szelethus Subscribers: mgorny, xazax.hun, baloghadamsoftware, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, jdoerfert, Charusso, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59279 llvm-svn: 361664
* Add some notes on immutability and faithfulness to the internals manual.Richard Smith2019-05-221-1/+92
| | | | llvm-svn: 361433
* [Docs] Increase Doxygen cache sizeDon Hinton2019-05-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: When building Doxygen docs for llvm and clang, it helpfully prints a warning at the end noting that the `LOOKUP_CACHE_SIZE` value was too small to keep all symbols in memory. By increasing to the size it recommends, Doxygen builds have greatly improved performance. On my machine, time to run `doxygen-llvm` changes from 34 minutes to 22 minutes, which is a decent amount of time saved by changing a single number. Reviewed By: hintonda Patch by J. Ryan Stinnett! Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D62138 llvm-svn: 361343
* [PragmaHandler] Expose `#pragma` locationJoel E. Denny2019-05-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Currently, a pragma AST node's recorded location starts at the namespace token (such as `omp` in the case of OpenMP) after the `#pragma` token, and the `#pragma` location isn't available. However, the `#pragma` location can be useful when, for example, rewriting a directive using Clang's Rewrite facility. This patch makes `#pragma` locations available in any `PragmaHandler` but it doesn't yet make use of them. This patch also uses the new `struct PragmaIntroducer` to simplify `Preprocessor::HandlePragmaDirective`. It doesn't do the same for `PPCallbacks::PragmaDirective` because that changes the API documented in `clang-tools-extra/docs/pp-trace.rst`, and I'm not sure about backward compatibility guarantees there. Reviewed By: ABataev, lebedev.ri, aaron.ballman Differential Revision: https://reviews.llvm.org/D61643 llvm-svn: 361335
* [Clang][Docs] Document __FILE_NAME__. NFCKristina Brooks2019-05-171-0/+5
| | | | | | Document the `__FILE_NAME__` preprocessor extension. llvm-svn: 360994
OpenPOWER on IntegriCloud