summaryrefslogtreecommitdiffstats
path: root/clang/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [clang-rename] NFC, make getCanonicalSymbolDeclaration robust on nullptr input.Haojian Wu2019-10-251-0/+2
|
* Fix compilation warning. NFC.Michael Liao2019-10-251-0/+1
|
* [hip] Allow the declaration of functions with variadic arguments in HIP.Michael Liao2019-10-253-0/+12
| | | | | | | | | | | | | | | | | Summary: - As variadic parameters have the lowest rank in overload resolution, without real usage of `va_arg`, they are commonly used as the catch-all fallbacks in SFINAE. As the front-end still reports errors on calls to `va_arg`, the declaration of functions with variadic arguments should be allowed in general. Reviewers: jlebar, tra, yaxunl Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69389
* [clang][DependencyScanning] clang-format.Michael Spencer2019-10-241-2/+3
|
* [clang][ThinLTO] Promote cc1 -fthin_link_bitcode to driver ↵Yuanfang Chen2019-10-241-0/+3
| | | | | | | | | | | | | | | | | -fthinlto_link_bitcode Summary: A necessary step to let build system caching work for its output. Reviewers: tejohnson, steven_wu Reviewed by: tejohnson Subscribers: mehdi_amini, inglorion, dexonsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69406
* Revert "Recommit "[Clang] Pragma vectorize_width() implies vectorize(enable)""Jordan Rupprecht2019-10-241-8/+0
| | | | | | | | | | | | | | This reverts commit 80371c74ae63d2f260bcc75408be9c6f81e38465. Given the following source: ``` void a() { for (;;) ; } ``` It incorrectly enables vectorization (with vector width 1), as well as generating a warning that vectorization could not be performed.
* [clang-scan-deps] Add basic support for modules.Michael Spencer2019-10-241-4/+38
| | | | | | | | | | | | | | | | | | | | This fixes two issues that prevent simple uses of modules from working. * We would previously minimize _every_ file opened by clang, even module maps and module pcm files. Now we only minimize files with known extensions. It would be better if we knew which files clang intended to open as a source file, but this works for now. * We previously cached every lookup, even failed lookups. This is a problem because clang stats the module cache directory before building a module and creating that directory. If we cache that failure then the subsequent pcm load doesn't see the module cache and fails. Overall this still leaves us building minmized modules on disk during scanning. This will need to be improved eventually for performance, but this is correct, and works for now. Differential Revision: https://reviews.llvm.org/D68835
* [clang]Fixup clang -Werror,,-Wcovered-switch-default build failuresJinsong Ji2019-10-241-3/+0
| | | | | | | | | llvm/clang/lib/CodeGen/CGBuiltin.cpp:6877:3: error: default label in switch which covers all enumeration values [-Werror,-Wcovered-switch-default] Similar to https://reviews.llvm.org/rG7b3de1e811972b874d91554642ccb2ef5b32eed6
* When diagnosing an ambiguity, only note the candidates that contributeRichard Smith2019-10-244-38/+69
| | | | to the ambiguity, rather than noting all viable candidates.
* [Concepts] Constraint Enforcement & DiagnosticsSaar Raz2019-10-2514-115/+599
| | | | | | Part of the C++20 concepts implementation effort. - Associated constraints (requires clauses, currently) are now enforced when instantiating/specializing templates and when considering partial specializations and function overloads. - Elaborated diagnostics give helpful insight as to why the constraints were not satisfied. Phabricator: D41569
* Follow on to Namespace fixup for D68340David Tenty2019-10-241-1/+0
| | | | remove using directive that can make lookup ambiguous.
* Namespace fixup for D68340 build on MSVCDavid Tenty2019-10-241-0/+2
| | | | | we seem to run into issues with nested namespace lookups in recently landed D68340 so just make them explicit.
* [clang-format] Remove duplciate code from Invalid BOM detectionpaulhoad2019-10-241-14/+24
| | | | | | | | | | | | | | | | | | | | | | Summary: Review comments on {D68767} asked that this duplicated code in clang-format was moved to one central location that being SourceManager (where it had originally be copied from I assume) Moved function into static function ContentCache::getInvalidBOM(...) - (closest class to where it was defined before) Updated clang-format to call this static function Added unit tests for said new function in BasicTests Sorry not my normal code area so may have the wrong reviewers. (but your names were on the recent history) Reviewers: bruno, arphaman, klimek, owenpan, mitchell-stellar, dexonsmith Reviewed By: owenpan Subscribers: cfe-commits Tags: #clang, #clang-format, #clang-tools-extra Differential Revision: https://reviews.llvm.org/D68914
* Add AIX toolchain and basic linker functionalitystevewan2019-10-244-0/+169
| | | | | | | | | | | | | | | | Summary: This patch adds AIX toolchain infrastructure into driver, and enables AIX system linker invocation with some basic functionality support Reviewers: daltenty, hubert.reinterpretcast, jasonliu, Xiangling_L Reviewed By: jasonliu Subscribers: Xiangling_L, jasonliu, ormris, wuzish, nemanjai, mgorny, kbarton, jfb, jsji, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68340
* [clang,ARM] Initial ACLE intrinsics for MVE.Simon Tatham2019-10-246-10/+239
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit sets up the infrastructure for auto-generating <arm_mve.h> and doing clang-side code generation for the builtins it relies on, and demonstrates that it works by implementing a representative sample of the ACLE intrinsics, more or less matching the ones introduced in LLVM IR by D67158,D68699,D68700. Like NEON, that header file will provide a set of vector types like uint16x8_t and C functions with names like vaddq_u32(). Unlike NEON, the ACLE spec for <arm_mve.h> includes a polymorphism system, so that you can write plain vaddq() and disambiguate by the vector types you pass to it. Unlike the corresponding NEON code, I've arranged to make every user- facing ACLE intrinsic into a clang builtin, and implement all the code generation inside clang. So <arm_mve.h> itself contains nothing but typedefs and function declarations, with the latter all using the new `__attribute__((__clang_builtin))` system to arrange that the user- facing function names correspond to the right internal BuiltinIDs. So the new MveEmitter tablegen system specifies the full sequence of IRBuilder operations that each user-facing ACLE intrinsic should translate into. Where possible, the ACLE intrinsics map to standard IR operations such as vector-typed `add` and `fadd`; where no standard representation exists, I call down to the sample IR intrinsics introduced in an earlier commit. Doing it like this means that you get the polymorphism for free just by using __attribute__((overloadable)): the clang overload resolution decides which function declaration is the relevant one, and _then_ its BuiltinID is looked up, so by the time we're doing code generation, that's all been resolved by the standard system. It also means that you get really nice error messages if the user passes the wrong combination of types: clang will show the declarations from the header file and explain why each one doesn't match. (The obvious alternative approach would be to have wrapper functions in <arm_mve.h> which pass their arguments to the underlying builtins. But that doesn't work in the case where one of the arguments has to be a constant integer: the wrapper function can't pass the constantness through. So you'd have to do that case using a macro instead, and then use C11 `_Generic` to handle the polymorphism. Then you have to add horrible workarounds because `_Generic` requires even the untaken branches to type-check successfully, and //then// if the user gets the types wrong, the error message is totally unreadable!) Reviewers: dmgreen, miyuki, ostannard Subscribers: mgorny, javed.absar, kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67161
* [clang] New __attribute__((__clang_arm_mve_alias)).Simon Tatham2019-10-242-4/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows you to declare a function with a name of your choice (say `foo`), but have clang treat it as if it were a builtin function (say `__builtin_foo`), by writing static __inline__ __attribute__((__clang_arm_mve_alias(__builtin_foo))) int foo(args); I'm intending to use this for the ACLE intrinsics for MVE, which have to be polymorphic on their argument types and also need to be implemented by builtins. To avoid having to implement the polymorphism with several layers of nested _Generic and make error reporting hideous, I want to make all the user-facing intrinsics correspond directly to clang builtins, so that after clang resolves __attribute__((overloadable)) polymorphism it's already holding the right BuiltinID for the intrinsic it selected. However, this commit itself just introduces the new attribute, and doesn't use it for anything. To avoid unanticipated side effects if this attribute is used to make aliases to other builtins, there's a restriction mechanism: only (BuiltinID, alias) pairs that are approved by the function ArmMveAliasValid() will be permitted. At present, that function doesn't permit anything, because the Tablegen that will generate its list of valid pairs isn't yet implemented. So the only test of this facility is one that checks that an unapproved builtin _can't_ be aliased. Reviewers: dmgreen, miyuki, ostannard Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67159
* Don't add -fsplit-lto-unit for thin LTO builds with PS4 and Darwin toolchainsevgeny2019-10-243-1/+10
| | | | | These toolchains use legacy thin LTO API, which is not capable of unit splitting Differential revision: https://reviews.llvm.org/D69173
* [analyzer] Fix off-by-one in operator call parameter binding.Artem Dergachev2019-10-231-1/+1
| | | | | | | | | | | | | | Member operator declarations and member operator expressions have different numbering of parameters and arguments respectively: one of them includes "this", the other does not. Account for this inconsistency when figuring out whether the parameter needs to be manually rebound from the Environment to the Store when entering a stack frame of an operator call, as opposed to being constructed with a constructor and as such already having the necessary Store bindings. Differential Revision: https://reviews.llvm.org/D69155
* [Mips] Use appropriate private label prefix based on Mips ABIMirko Brkusanin2019-10-231-3/+4
| | | | | | | | | | MipsMCAsmInfo was using '$' prefix for Mips32 and '.L' for Mips64 regardless of -target-abi option. By passing MCTargetOptions to MCAsmInfo we can find out Mips ABI and pick appropriate prefix. Tags: #llvm, #clang, #lldb Differential Revision: https://reviews.llvm.org/D66795
* [c++2a] Allow comparison functions to be explicitly defaulted.Richard Smith2019-10-226-85/+260
| | | | | | This adds some initial syntactic checking that only the appropriate function signatures can be defaulted. No implicit definitions are generated yet.
* Revert r374202"[ObjC generics] Fix not inheriting type bounds in ↵Hans Wennborg2019-10-221-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | categories/extensions." This introduced new errors, see below. Reverting until that can be investigated properly. #import <AVFoundation/AVFoundation.h> void f(int width, int height) { FourCharCode best_fourcc = kCMPixelFormat_422YpCbCr8_yuvs; NSDictionary* videoSettingsDictionary = @{ (id)kCVPixelBufferPixelFormatTypeKey : @(best_fourcc), }; } $ clang++ -c /tmp/a.mm /tmp/a.mm:6:5: error: cannot initialize a parameter of type 'KeyType<NSCopying> _Nonnull const' (aka 'const id') with an rvalue of type 'id' (id)kCVPixelBufferPixelFormatTypeKey : @(best_fourcc), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. > When a category/extension doesn't repeat a type bound, corresponding > type parameter is substituted with `id` when used as a type argument. As > a result, in the added test case it was causing errors like > > > type argument 'T' (aka 'id') does not satisfy the bound ('id<NSCopying>') of type parameter 'T' > > We are already checking that type parameters should be consistent > everywhere (see `checkTypeParamListConsistency`) and update > `ObjCTypeParamDecl` to have correct underlying type. And when we use the > type parameter as a method return type or a method parameter type, it is > substituted to the bounded type. But when we use the type parameter as a > type argument, we check `ObjCTypeParamType` that ignores the updated > underlying type and remains `id`. > > Fix by desugaring `ObjCTypeParamType` to the underlying type, the same > way we are doing with `TypedefType`. > > rdar://problem/54329242 > > Reviewers: erik.pilkington, ahatanak > > Reviewed By: erik.pilkington > > Subscribers: jkorous, dexonsmith, ributzka, cfe-commits > > Differential Revision: https://reviews.llvm.org/D66696
* Fix name of warn_ignored_hip_only_optionYaxun (Sam) Liu2019-10-221-1/+1
| | | | Differential Revision: https://reviews.llvm.org/D69268
* [RISCV] Add support for -ffixed-xX flagsSimon Cook2019-10-221-0/+64
| | | | | | | | | | | This adds support for reserving GPRs such that the compiler will not choose a register for register allocation. The implementation follows the same design as for AArch64; each reserved register becomes a target feature and used for getting the reserved registers for a given MachineFunction. The backend checks that it does not need to write to any reserved register; if it does a relevant error is generated. Differential Revision: https://reviews.llvm.org/D67185
* [HIP] Add option -fgpu-allow-device-initYaxun (Sam) Liu2019-10-224-1/+19
| | | | | | | | | | | | | | Add this option to allow device side class type global variables with non-trivial ctor/dtor. device side init/fini functions will be emitted, which will be executed by HIP runtime when the fat binary is loaded/unloaded. This feature is to facilitate implementation of device side sanitizer which requires global vars with non-trival ctors. By default this option is disabled. Differential Revision: https://reviews.llvm.org/D69268
* Refactor DependencyScanningTool to its own fileKousik Kumar2019-10-222-0/+72
| | | | | | | | | | | | | | | | | Summary: There's no behavior change - just moving DependencyScanningTool to its own file since this tool can be reused across both clang-scan-deps binary and an interface exposed as part of libClang APIs. Reviewers: arphaman, jkorous, Bigcheese, dexonsmith Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69186 llvm-svn: 375483
* Minor coding style fix. NFC.Michael Liao2019-10-221-1/+2
| | | | llvm-svn: 375478
* Fix -fuse-init-array decision logic on NetBSDJoerg Sonnenberger2019-10-211-1/+14
| | | | | | | For NetBSD 9 and later, it is the default. On older versions, only ARM and AArch64 use it by default. llvm-svn: 375468
* [Implicit Modules] Add -cc1 option -fmodules-strict-context-hash which ↵Michael J. Spencer2019-10-211-0/+20
| | | | | | | | includes search paths and diagnostics. This is a recommit of r375322 and r375327 with a fix for the Windows test breakage. llvm-svn: 375466
* SemaTemplateDeduction - silence static analyzer getAs<> null dereference ↵Simon Pilgrim2019-10-211-7/+3
| | | | | | | | warnings. NFCI. The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 375443
* [Clang] Add VerboseOutputStream to CompilerInstanceScott Linder2019-10-211-3/+11
| | | | | | | | | | | | Remove one instance of a hardcoded output stream in CompilerInstance::ExecuteAction. There are still other cases of output being hard-coded to standard streams in ExecuteCompilerInvocation, but this patch covers the case when no flags like -version or -help are passed, namely the "X warnings and Y errors generated." diagnostic. Differential Revision: https://reviews.llvm.org/D53768 llvm-svn: 375442
* SemaExceptionSpec - silence static analyzer getAs<> null dereference ↵Simon Pilgrim2019-10-211-4/+3
| | | | | | | | warnings. NFCI. The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 375440
* Prune include of DataLayout.h from include/clang/Basic/TargetInfo.h. NFCBjorn Pettersson2019-10-213-0/+7
| | | | | | | | | | | | | | | | | | | | | | | Summary: Use a forward declaration of DataLayout instead of including DataLayout.h in clangs TargetInfo.h. This reduces include dependencies toward DataLayout.h (and other headers such as DerivedTypes.h, Type.h that is included by DataLayout.h). Needed to move implemantation of TargetInfo::resetDataLayout from TargetInfo.h to TargetInfo.cpp. Reviewers: rnk Reviewed By: rnk Subscribers: jvesely, nhaehnle, cfe-commits, llvm-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69262 llvm-svn: 375438
* Prune Pass.h include from DataLayout.h. NFCIBjorn Pettersson2019-10-211-0/+1
| | | | | | | | | | | | | | | | | | | Summary: Reduce include dependencies by no longer including Pass.h from DataLayout.h. That include seemed irrelevant to DataLayout, as well as being irrelevant to several users of DataLayout. Reviewers: rnk Reviewed By: rnk Subscribers: mehdi_amini, hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D69261 llvm-svn: 375436
* PCH debug info: Avoid appending the source directory to an absolute pathAdrian Prantl2019-10-211-3/+3
| | | | | | | | | | | | | | When building a precompiled header in -fmodule-format=obj (i.e., `-gmodules) in an absolute path, the locig in CGDebugInfo::createCompileUnit would unconditionally append the source directory to the -main-file-name. This patch avoids that behavior for absolute paths. rdar://problem/46045865 Differential Revision: https://reviews.llvm.org/D69213 llvm-svn: 375423
* [AMDGPU] Fix assertion due to initializer listYaxun Liu2019-10-201-10/+6
| | | | | | | | | | | | | Sometimes a global var is replaced by a different llvm value. clang use GetAddrOfGlobalVar to get the original llvm global variable. For most targets, GetAddrOfGlobalVar returns either the llvm global variable or a bitcast of the llvm global variable. However, for AMDGPU target, GetAddrOfGlobalVar returns the addrspace cast or addrspace cast plus bitcast of the llvm global variable. To get the llvm global variable, these casts need to be stripped, otherwise there is assertion. This patch fixes that. Differential Revision: https://reviews.llvm.org/D69129 llvm-svn: 375362
* Revert "[Implicit Modules] Add -cc1 option -fmodules-strict-context-hash ↵Michael J. Spencer2019-10-191-20/+0
| | | | | | | | which includes search paths and diagnostics." and "[Docs] Fix header level." The test doesn't work on Windows. I'll fix it and recommit later. llvm-svn: 375338
* [analyzer] PR43551: Do not dereferce void* in UndefOrNullArgVisitor.Artem Dergachev2019-10-191-3/+5
| | | | | | | | Patch by Kristóf Umann! Differential Revision: https://reviews.llvm.org/D68591 llvm-svn: 375329
* [analyzer] Fix a crash on tracking Objective-C 'self' as a control dependency.Artem Dergachev2019-10-191-7/+12
| | | | | | | 'self' was previously never tracked, but now it can be tracked because it may be part of a condition. llvm-svn: 375328
* Add -Wbitwise-conditional-parentheses to warn on mixing '|' and '&' with "?:"Richard Trieu2019-10-191-2/+11
| | | | | | | | | | | | | | | | | | | | Extend -Wparentheses to cover mixing bitwise-and and bitwise-or with the conditional operator. There's two main cases seen with this: unsigned bits1 = 0xf0 | cond ? 0x4 : 0x1; unsigned bits2 = cond1 ? 0xf0 : 0x10 | cond2 ? 0x5 : 0x2; // Intended order of evaluation: unsigned bits1 = 0xf0 | (cond ? 0x4 : 0x1); unsigned bits2 = (cond1 ? 0xf0 : 0x10) | (cond2 ? 0x5 : 0x2); // Actual order of evaluation: unsigned bits1 = (0xf0 | cond) ? 0x4 : 0x1; unsigned bits2 = cond1 ? 0xf0 : ((0x10 | cond2) ? 0x5 : 0x2); Differential Revision: https://reviews.llvm.org/D66043 llvm-svn: 375326
* [Implicit Modules] Add -cc1 option -fmodules-strict-context-hash which ↵Michael J. Spencer2019-10-191-0/+20
| | | | | | | | includes search paths and diagnostics. Differential Revision: https://reviews.llvm.org/D68528 llvm-svn: 375322
* New tautological warning for bitwise-or with non-zero constant always true.Richard Trieu2019-10-192-7/+58
| | | | | | | | | | | | | | | | | | Taking a value and the bitwise-or it with a non-zero constant will always result in a non-zero value. In a boolean context, this is always true. if (x | 0x4) {} // always true, intended '&' This patch creates a new warning group -Wtautological-bitwise-compare for this warning. It also moves in the existing tautological bitwise comparisons into this group. A few other changes were needed to the CFGBuilder so that all bool contexts would be checked. The warnings in -Wtautological-bitwise-compare will be off by default due to using the CFG. Fixes: https://bugs.llvm.org/show_bug.cgi?id=42666 Differential Revision: https://reviews.llvm.org/D66046 llvm-svn: 375318
* Move endian constant from Host.h to SwapByteOrder.h, prune includeReid Kleckner2019-10-194-0/+4
| | | | | | | | | | | | | | Works on this dependency chain: ArrayRef.h -> Hashing.h -> --CUT-- Host.h -> StringMap.h / StringRef.h ArrayRef is very popular, but Host.h is rarely needed. Move the IsBigEndianHost constant to SwapByteOrder.h. Clients of that header are more likely to need it. llvm-svn: 375316
* Sema: Create a no-op implicit cast for lvalue function conversions.Peter Collingbourne2019-10-194-35/+50
| | | | | | | | | | This fixes an assertion failure in the case where an implicit conversion for a function call involves an lvalue function conversion, and makes the AST for initializations involving implicit lvalue function conversions more accurate. Differential Revision: https://reviews.llvm.org/D66437 llvm-svn: 375313
* [clang][driver] Print compilation phases with indentation.Michael Liao2019-10-191-5/+24
| | | | | | | | | | | | Reviewers: tra, sfantao, echristo Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69124 llvm-svn: 375310
* [hip][cuda] Fix the extended lambda name mangling issue.Michael Liao2019-10-196-24/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - HIP/CUDA host side needs to use device kernel symbol name to match the device side binaries. Without a consistent naming between host- and device-side compilations, it's risky that wrong device binaries are executed. Consistent naming is usually not an issue until unnamed types are used, especially the lambda. In this patch, the consistent name mangling is addressed for the extended lambdas, i.e. the lambdas annotated with `__device__`. - In [Itanium C++ ABI][1], the mangling of the lambda is generally unspecified unless, in certain cases, ODR rule is required to ensure consisent naming cross TUs. The extended lambda is such a case as its name may be part of a device kernel function, e.g., the extended lambda is used as a template argument and etc. Thus, we need to force ODR for extended lambdas as they are referenced in both device- and host-side TUs. Furthermore, if a extended lambda is nested in other (extended or not) lambdas, those lambdas are required to follow ODR naming as well. This patch revises the current lambda mangle numbering to force ODR from an extended lambda to all its parent lambdas. - On the other side, the aforementioned ODR naming should not change those lambdas' original linkages, i.e., we cannot replace the original `internal` with `linkonce_odr`; otherwise, we may violate ODR in general. This patch introduces a new field `HasKnownInternalLinkage` in lambda data to decouple the current linkage calculation based on mangling number assigned. [1]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html Reviewers: tra, rsmith, yaxunl, martong, shafik Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68818 llvm-svn: 375309
* [c++20] Add rewriting from comparison operators to <=> / ==.Richard Smith2019-10-197-129/+430
| | | | | | | | | | | | | | | | | This adds support for rewriting <, >, <=, and >= to a normal or reversed call to operator<=>, for rewriting != to a normal or reversed call to operator==, and for rewriting <=> and == to reversed forms of those same operators. Note that this is a breaking change for various C++17 code patterns, including some in use in LLVM. The most common patterns (where an operator== becomes ambiguous with a reversed form of itself) are still accepted under this patch, as an extension (with a warning). I'm hopeful that we can get the language rules fixed before C++20 ships, and the extension warning is aimed primarily at providing data to inform that decision. llvm-svn: 375306
* [c++20] Add CXXRewrittenBinaryOperator to represent a comparisonRichard Smith2019-10-1917-0/+181
| | | | | | | | operator that is rewritten as a call to multiple other operators. No functionality change yet: nothing creates these expressions. llvm-svn: 375305
* DebugInfo: Render the canonical name of a class template specialization, ↵David Blaikie2019-10-182-2/+5
| | | | | | | | even when nested in another class template specialization Differential Revision: https://reviews.llvm.org/D63031 llvm-svn: 375304
* [profile] Do not cache __llvm_profile_get_filename resultVedant Kumar2019-10-181-1/+0
| | | | | | | | | | | | | | | | | When the %m filename pattern is used, the filename is unique to each image, so the cached value is wrong. It struck me that the full filename isn't something that's recomputed often, so perhaps it doesn't need to be cached at all. David Li pointed out we can go further and just hide lprofCurFilename. This may regress workflows that depend on using the set-filename API to change filenames across all loaded DSOs, but this is expected to be very rare. rdar://55137071 Differential Revision: https://reviews.llvm.org/D69137 llvm-svn: 375301
* [analyzer] Fix FieldRegion dumps.Artem Dergachev2019-10-181-1/+1
| | | | | | | | | The '->' thing has always been confusing; the actual operation '->' translates to a pointer dereference together with adding a FieldRegion, but FieldRegion on its own doesn't imply an additional pointer dereference. llvm-svn: 375281
OpenPOWER on IntegriCloud