summaryrefslogtreecommitdiffstats
path: root/clang/include
Commit message (Collapse)AuthorAgeFilesLines
...
* [P0936R0] add [[clang::lifetimebound]] attributeRichard Smith2018-08-014-0/+38
| | | | | | | | | | | | | | | | | | | This patch adds support for a new attribute, [[clang::lifetimebound]], that indicates that the lifetime of a function result is related to one of the function arguments. When walking an initializer to make sure that the lifetime of the initial value is at least as long as the lifetime of the initialized object, we step through parameters (including the implicit object parameter of a non-static member function) that are marked with this attribute. There's nowhere to write an attribute on the implicit object parameter, so in lieu of that, it may be applied to a function type (where it appears immediately after the cv-qualifiers and ref-qualifier, which is as close to a declaration of the implicit object parameter as we have). I'm currently modeling this in the AST as the attribute appertaining to the function type. Differential Revision: https://reviews.llvm.org/D49922 llvm-svn: 338464
* [constexpr] Support for constant evaluation of __builtin_memcpy andRichard Smith2018-07-312-0/+18
| | | | | | | | | | | | | | __builtin_memmove (in non-type-punning cases). This is intended to permit libc++ to make std::copy etc constexpr without sacrificing the optimization that uses memcpy on trivially-copyable types. __builtin_strcpy and __builtin_wcscpy are not handled by this change. They'd be straightforward to add, but we haven't encountered a need for them just yet. llvm-svn: 338455
* [CFG] [analyzer] NFC: Enumerate construction context layer kinds.Artem Dergachev2018-07-312-57/+193
| | | | | | | | | | | | | | This is a refactoring patch; no functional change intended. The common part of ConstructionContextLayer and ConstructedObjectKey is factored out into a new structure, ConstructionContextItem. Various sub-kinds of ConstructionContextItem are enumerated in order to provide richer information about construction contexts. Differential Revision: https://reviews.llvm.org/D49210. llvm-svn: 338439
* [CFG] [analyzer] Implement function argument construction contexts.Artem Dergachev2018-07-312-7/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | In r330377 and r338425 we have already identified what constitutes function argument constructors and added stubs in order to prevent confusing them with other temporary object constructors. Now we implement a ConstructionContext sub-class to carry all the necessary information about the construction site, namely call expression and argument index. On the analyzer side, the patch interacts with the recently implemented pre-C++17 copy elision support in an interesting manner. If on the CFG side we didn't find a construction context for the elidable constructor, we build the CFG as if the elidable constructor is not elided, and the non-elided constructor within it is a simple temporary. But the same problem may occur in the analyzer: if the elidable constructor has a construction context but the analyzer doesn't implement such context yet, the analyzer should also try to skip copy elision and still inline the non-elided temporary constructor. This was implemented by adding a "roll back" mechanism: when elision fails, roll back the changes and proceed as if it's a simple temporary. The approach is wonky, but i'm fine with that as long as it's merely a defensive mechanism that should eventually go away once all construction contexts become supported. Differential Revision: https://reviews.llvm.org/D48681. llvm-svn: 338436
* [analyzer] Move InnerPointerChecker out of alpha.Reka Kovacs2018-07-311-4/+4
| | | | | | Differential Revision: https://reviews.llvm.org/D49058 llvm-svn: 338433
* [CFG] [analyzer] Add construction contexts for returning C++ objects in ObjC++.Artem Dergachev2018-07-311-12/+16
| | | | | | | | | | | Like any normal funciton, Objective-C message can return a C++ object in Objective-C++. Such object would require a construction context. This patch, therefore, is an extension of r327343 onto Objective-C++. Differential Revision: https://reviews.llvm.org/D48608 llvm-svn: 338426
* [COFF, ARM64] Enable SEH for ARM64 WindowsMandeep Singh Grang2018-07-311-1/+2
| | | | | | | | | | | | Reviewers: rnk, mstorsjo, ssijaric, haripul, TomTan Reviewed By: rnk Subscribers: kristof.beyls, chrib, cfe-commits Differential Revision: https://reviews.llvm.org/D50029 llvm-svn: 338405
* [Sema] Relax a failing assert in TemplateArgumentLocErik Pilkington2018-07-311-1/+7
| | | | | | | | | | | | | Any of these template argument kinds can be represented with an expression, so accept them in this constructor. Patch by Balaji Iyer! rdar://41459965 Differential revision: https://reviews.llvm.org/D49766 llvm-svn: 338338
* [analyzer] [NFC] Simplify some visitors by giving a convenient getter from ↵George Karpenkov2018-07-301-0/+3
| | | | | | | | state to analysis manager Differential Revision: https://reviews.llvm.org/D49772 llvm-svn: 338315
* Avoid returning an invalid end source locStephen Kelly2018-07-301-2/+4
| | | | llvm-svn: 338301
* Remove trailing spaceFangrui Song2018-07-30194-1980/+1980
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [clang][ubsan] Implicit Conversion Sanitizer - integer truncation - clang partRoman Lebedev2018-07-302-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: C and C++ are interesting languages. They are statically typed, but weakly. The implicit conversions are allowed. This is nice, allows to write code while balancing between getting drowned in everything being convertible, and nothing being convertible. As usual, this comes with a price: ``` unsigned char store = 0; bool consume(unsigned int val); void test(unsigned long val) { if (consume(val)) { // the 'val' is `unsigned long`, but `consume()` takes `unsigned int`. // If their bit widths are different on this platform, the implicit // truncation happens. And if that `unsigned long` had a value bigger // than UINT_MAX, then you may or may not have a bug. // Similarly, integer addition happens on `int`s, so `store` will // be promoted to an `int`, the sum calculated (0+768=768), // and the result demoted to `unsigned char`, and stored to `store`. // In this case, the `store` will still be 0. Again, not always intended. store = store + 768; // before addition, 'store' was promoted to int. } // But yes, sometimes this is intentional. // You can either make the conversion explicit (void)consume((unsigned int)val); // or mask the value so no bits will be *implicitly* lost. (void)consume((~((unsigned int)0)) & val); } ``` Yes, there is a `-Wconversion`` diagnostic group, but first, it is kinda noisy, since it warns on everything (unlike sanitizers, warning on an actual issues), and second, there are cases where it does **not** warn. So a Sanitizer is needed. I don't have any motivational numbers, but i know i had this kind of problem 10-20 times, and it was never easy to track down. The logic to detect whether an truncation has happened is pretty simple if you think about it - https://godbolt.org/g/NEzXbb - basically, just extend (using the new, not original!, signedness) the 'truncated' value back to it's original width, and equality-compare it with the original value. The most non-trivial thing here is the logic to detect whether this `ImplicitCastExpr` AST node is **actually** an implicit conversion, //or// part of an explicit cast. Because the explicit casts are modeled as an outer `ExplicitCastExpr` with some `ImplicitCastExpr`'s as **direct** children. https://godbolt.org/g/eE1GkJ Nowadays, we can just use the new `part_of_explicit_cast` flag, which is set on all the implicitly-added `ImplicitCastExpr`'s of an `ExplicitCastExpr`. So if that flag is **not** set, then it is an actual implicit conversion. As you may have noted, this isn't just named `-fsanitize=implicit-integer-truncation`. There are potentially some more implicit conversions to be warned about. Namely, implicit conversions that result in sign change; implicit conversion between different floating point types, or between fp and an integer, when again, that conversion is lossy. One thing i know isn't handled is bitfields. This is a clang part. The compiler-rt part is D48959. Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=21530 | PR21530 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=37552 | PR37552 ]], [[ https://bugs.llvm.org/show_bug.cgi?id=35409 | PR35409 ]]. Partially fixes [[ https://bugs.llvm.org/show_bug.cgi?id=9821 | PR9821 ]]. Fixes https://github.com/google/sanitizers/issues/940. (other than sign-changing implicit conversions) Reviewers: rjmccall, rsmith, samsonov, pcc, vsk, eugenis, efriedma, kcc, erichkeane Reviewed By: rsmith, vsk, erichkeane Subscribers: erichkeane, klimek, #sanitizers, aaron.ballman, RKSimon, dtzWill, filcab, danielaustin, ygribov, dvyukov, milianw, mclow.lists, cfe-commits, regehr Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D48958 llvm-svn: 338288
* [analyzer] Store ValueDecl in DeclRegionGeorge Karpenkov2018-07-301-3/+3
| | | | | | | | | All use cases of DeclRegion actually have ValueDecl there, and getting the name from declaration comes in very handy. Differential Revision: https://reviews.llvm.org/D49998 llvm-svn: 338286
* [ARM, AArch64]: Use unadjusted alignment when passing composites as argumentsMomchil Velikov2018-07-302-0/+32
| | | | | | | | | | | | | | | | | | The "Procedure Call Procedure Call Standard for the ARM® Architecture" (https://static.docs.arm.com/ihi0042/f/IHI0042F_aapcs.pdf), specifies that composite types are passed according to their "natural alignment", i.e. the alignment before alignment adjustment on the entire composite is applied. The same applies for AArch64 ABI. Clang, however, used the adjusted alignment. GCC already implements the ABI correctly. With this patch Clang becomes compatible with GCC and passes such arguments in accordance with AAPCS. Differential Revision: https://reviews.llvm.org/D46013 llvm-svn: 338279
* Fix -Wdocumentation warning. NFCI.Simon Pilgrim2018-07-301-1/+0
| | | | llvm-svn: 338238
* [Sema][ObjC] Warn when a method declared in a protocol takes aAkira Hatanaka2018-07-281-0/+2
| | | | | | | | | | | non-escaping parameter but the implementation's method takes an escaping parameter. rdar://problem/39548196 Differential Revision: https://reviews.llvm.org/D49119 llvm-svn: 338189
* [CUDA][HIP] Allow function-scope static const variableYaxun Liu2018-07-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | CUDA 8.0 E.3.9.4 says: Within the body of a __device__ or __global__ function, only __shared__ variables or variables without any device memory qualifiers may be declared with static storage class. It is unclear how a function-scope non-const static variable without device memory qualifier is implemented, therefore only static const variable without device memory qualifier is allowed, which can be emitted as a global variable in constant address space. Currently clang only allows function-scope static variable with __shared__ qualifier. This patch also allows function-scope static const variable without device memory qualifier and emits it as a global variable in constant address space. Differential Revision: https://reviews.llvm.org/D49931 llvm-svn: 338188
* [AST] Add a convenient getter from QualType to RecordDeclGeorge Karpenkov2018-07-281-0/+3
| | | | | | Differential Revision: https://reviews.llvm.org/D49951 llvm-svn: 338187
* [CFG] Remove duplicate function/class names at the beginning of commentsFangrui Song2018-07-283-68/+61
| | | | | | | | Some functions/classes have renamed while the comments still use the old names. Delete them per coding style. Also some whitespace cleanup. llvm-svn: 338183
* Parse a possible trailing postfix expression suffix after a fold expressionNicolas Lesser2018-07-271-0/+1
| | | | | | | | | | | | | | | | | Summary: This patch allows the parsing of a postfix expression involving a fold expression, which is legal as a fold-expression is a primary-expression. See also https://llvm.org/pr38282 Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49848 llvm-svn: 338170
* [DEBUGINFO] Disable unsupported debug info options for NVPTX target.Alexey Bataev2018-07-273-0/+9
| | | | | | | | | | | | | | | | | | Summary: Some targets support only default set of the debug options and do not support additional debug options, like NVPTX target. Patch introduced virtual function supportsDebugInfoOptions() that can be overloaded by the toolchain, checks if the target supports some debug options and emits warning when an unsupported debug option is found. Reviewers: echristo Subscribers: aprantl, JDevlieghere, cfe-commits Differential Revision: https://reviews.llvm.org/D49148 llvm-svn: 338155
* Fix typos in comment.Richard Smith2018-07-271-2/+2
| | | | llvm-svn: 338141
* [ASTMatchers] Introduce a matcher for `ObjCIvarExpr`, support getting it's ↵George Karpenkov2018-07-271-0/+1
| | | | | | | | | | | | | declaration ObjCIvarExpr is *not* a subclass of MemberExpr, and a separate matcher is required to support it. Adding a hasDeclaration support as well, as it's not very useful without it. Differential Revision: https://reviews.llvm.org/D49701 llvm-svn: 338140
* [ASTMatchers] Introduce a matcher for `ObjCIvarExpr`, support getting it's ↵George Karpenkov2018-07-272-1/+24
| | | | | | | | | | | | | declaration. ObjCIvarExpr is *not* a subclass of MemberExpr, and a separate matcher is required to support it. Adding a hasDeclaration support as well, as it's not very useful without it. Differential Revision: https://reviews.llvm.org/D49701 llvm-svn: 338137
* [AST] Sink 'part of explicit cast' down into ImplicitCastExprRoman Lebedev2018-07-272-8/+8
| | | | | | | | | | | | | | | | | | | | | | | Summary: As discussed in IRC with @rsmith, it is slightly not good to keep that in the `CastExpr` itself: Given the explicit cast, which is represented in AST as an `ExplicitCastExpr` + `ImplicitCastExpr`'s, only the `ImplicitCastExpr`'s will be marked as `PartOfExplicitCast`, but not the `ExplicitCastExpr` itself. Thus, it is only ever `true` for `ImplicitCastExpr`'s, so we don't need to write/read/dump it for `ExplicitCastExpr`'s. We don't need to worry that we write the `PartOfExplicitCast` in PCH after `CastExpr::path_iterator`, since the `ExprImplicitCastAbbrev` is only used when the `NumBaseSpecs == 0`, i.e. there is no 'path'. Reviewers: rsmith, rjmccall, erichkeane, aaron.ballman Reviewed By: rsmith, erichkeane Subscribers: vsk, cfe-commits, rsmith Tags: #clang Differential Revision: https://reviews.llvm.org/D49838 llvm-svn: 338108
* [MS] Add L__FUNCSIG__ for compatibilityReid Kleckner2018-07-262-1/+3
| | | | | | | | | | Clang already has L__FUNCTION__ as a workaround for dealing with pre-processor code that expects to be able to do L##__FUNCTION__ in a macro. This patch implements the same logic for __FUNCSIG__. Fixes PR38295. llvm-svn: 338083
* [ARM64] [Windows] Follow MS X86_64 C++ ABI when passing structsSanjin Sijaric2018-07-261-1/+1
| | | | | | | | | | | | | | | | | Summary: Microsoft's C++ object model for ARM64 is the same as that for X86_64. For example, small structs with non-trivial copy constructors or virtual function tables are passed indirectly. Currently, they are passed in registers when compiled with clang. Reviewers: rnk, mstorsjo, TomTan, haripul, javed.absar Reviewed By: rnk, mstorsjo Subscribers: kristof.beyls, chrib, llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D49770 llvm-svn: 338076
* Refactor checking of switch conditions and case values.Richard Smith2018-07-263-4/+10
| | | | | | | | | | | | | | | | | | | Check each case value in turn while parsing it, performing the conversion to the switch type within the context of the expression itself. This will become necessary in order to properly handle cleanups for temporaries created as part of the case label (in an upcoming patch). For now it's just good hygiene. This necessitates moving the checking for the switch condition itself to earlier, so that the destination type is available when checking the case labels. As a nice side-effect, we get slightly improved diagnostic quality and error recovery by separating the case expression checking from the case statement checking and from tracking whether there are discarded case labels. llvm-svn: 338056
* [COFF, ARM64] Decide when to mark struct returns as SRetMandeep Singh Grang2018-07-261-2/+14
| | | | | | | | | | | | | | | | Summary: Refer the MS ARM64 ABI Convention for the behavior for struct returns: https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions#return-values Reviewers: mstorsjo, compnerd, rnk, javed.absar, yinma, efriedma Reviewed By: rnk, efriedma Subscribers: haripul, TomTan, yinma, efriedma, kristof.beyls, chrib, llvm-commits Differential Revision: https://reviews.llvm.org/D49464 llvm-svn: 338050
* [RISCV] Add support for interrupt attributeAna Pazos2018-07-263-1/+44
| | | | | | | | | | | | | | | | | | | Summary: Clang supports the GNU style ``__attribute__((interrupt))`` attribute on RISCV targets. Permissible values for this parameter are user, supervisor, and machine. If there is no parameter, then it defaults to machine. Reference: https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Function-Attributes.html Based on initial patch by Zhaoshi Zheng. Reviewers: asb, aaron.ballman Reviewed By: asb, aaron.ballman Subscribers: rkruppe, the_o, aaron.ballman, MartinMosbeck, brucehoult, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, mgrang, rogfer01, cfe-commits Differential Revision: https://reviews.llvm.org/D48412 llvm-svn: 338045
* [analyzer] Fixed method to get APSInt modelMikhail R. Gadelha2018-07-261-1/+2
| | | | | | | | | | | | | | | | | | | Summary: This patch replaces the current method of getting an `APSInt` from Z3's model by calling generic API method `getBitvector` instead of `Z3_get_numeral_uint64`. By calling `getBitvector`, there's no need to handle bitvectors with bit width == 128 separately. And, as a bonus, clang now compiles correctly with Z3 4.7.1. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49818 llvm-svn: 338020
* [ODRHash] Support hashing enums.Richard Trieu2018-07-254-1/+44
| | | | llvm-svn: 337978
* [analyzer] Update SMT API documentation and methodsMikhail R. Gadelha2018-07-255-101/+149
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Update the documentation of all the classes introduced with the new generic SMT API, most of them were referencing Z3 and how previous operations were being done (like including the context as parameter in a few methods). Renamed the following methods, so it's clear that the operate on bitvectors: *`mkSignExt` -> `mkBVSignExt` *`mkZeroExt` -> `mkBVZeroExt` *`mkExtract` -> `mkBVExtract` *`mkConcat` -> `mkBVConcat` Removed the unecessary methods: * `getDataExpr`: it was an one line method that called `fromData` * `mkBitvector(const llvm::APSInt Int)`: it was not being used anywhere Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49799 llvm-svn: 337954
* [analyzer] Fix compilation when LLVM_ENABLE_MODULES=ONMikhail R. Gadelha2018-07-253-1/+8
| | | | llvm-svn: 337948
* [clang:sema] de-duplicate getDepthAndIndex helpersNick Desaulniers2018-07-251-0/+21
| | | | | | | | | | | | | | | | | | | Summary: Continuing off of: https://reviews.llvm.org/D38382 Fixes: https://bugs.llvm.org/show_bug.cgi?id=12176 Reviewers: srhines, pirama, vsk Reviewed By: vsk Subscribers: cfe-commits, vsk, maitesin Differential Revision: https://reviews.llvm.org/D49760 llvm-svn: 337944
* [OPENMP] Exclude service expressions/statements from the list ofAlexey Bataev2018-07-251-1/+3
| | | | | | | | | | the children. Special internal helper expressions/statements for the OpenMP directives should not be exposed as children, only the main substatement must be represented as the child. llvm-svn: 337941
* [analyzer] Removed API used by the Refutation Manager from ↵Mikhail R. Gadelha2018-07-252-8/+2
| | | | | | | | | | | | | | | | | | | | | | | SMTConstraintManager and replace by proper calls to SMTSolver Summary: Third patch in the refactoring series, to decouple the SMT Solver from the Refutation Manager (1st: D49668, 2nd: D49767). The refutation API in the `SMTConstraintManager` was a hack to allow us to create an SMT solver and verify the constraints; it was conceptually wrong from the start. Now, we don't actually need to use the `SMTConstraintManager` and can create an SMT object directly, add the constraints and check them. While updating the Falsification visitor, I inlined the two functions that were used to collect the constraints and add them to the solver. As a result of this patch, we could move the SMT API elsewhere and as it's not really dependent on the CSA anymore. Maybe we can create a new dir (utils/smt) for Z3 and future solvers? Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49768 llvm-svn: 337922
* [analyzer] Moved code from SMTConstraintManager to SMTSolverMikhail R. Gadelha2018-07-252-183/+414
| | | | | | | | | | | | | | | | | Summary: This is the second part of D49668, and moves all the code that's not specific to a ConstraintManager to SMTSolver. No functional change intended. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49767 llvm-svn: 337921
* [analyzer] Moved non solver specific code from Z3ConstraintManager to ↵Mikhail R. Gadelha2018-07-251-5/+232
| | | | | | | | | | | | | | | | | | | | | | | SMTConstraintManager Summary: This patch moves a lot of code from `Z3ConstraintManager` to `SMTConstraintManager`, leaving only the necessary: * `canReasonAbout` which returns if a Solver can handle a given `SVal` (should be moved to `SMTSolver` in the future). * `removeDeadBindings`, `assumeExpr` and `print`: methods that need to use `ConstraintZ3Ty`, can probably be moved to `SMTConstraintManager` in the future. The patch creates a new file, `SMTConstraintManager.cpp` with the moved code. Conceptually, this is move in the right direction and needs further improvements: `SMTConstraintManager` still does a lot of things that are not required by a `ConstraintManager`. We ought to move the unrelated to `SMTSolver` and remove everything that's not related to a `ConstraintManager`. In particular, we could remove `addRangeConstraints` and `isModelFeasible`, and make the refutation manager create an Z3Solver directly. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: mgorny, xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49668 llvm-svn: 337919
* [analyzer] Implemented SMT generic APIMikhail R. Gadelha2018-07-251-0/+546
| | | | | | | | | | | | | | | | | Summary: Created new SMT generic API. Small changes to `Z3ConstraintManager` because of the new generic objects (`SMTSort` and `SMTExpr`) returned by `SMTSolver`. Reviewers: george.karpenkov, NoQ Reviewed By: george.karpenkov Subscribers: mgorny, xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49495 llvm-svn: 337918
* [analyzer] Create generic SMT Expr classMikhail R. Gadelha2018-07-251-0/+57
| | | | | | | | | | | | | | | | | Summary: New base class for all future SMT Exprs. No major changes except moving `areEquivalent` and `getFloatSemantics` outside of `Z3Expr` to keep the class minimal. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49551 llvm-svn: 337917
* [analyzer] Create generic SMT Sort ClassMikhail R. Gadelha2018-07-251-0/+71
| | | | | | | | | | | | | | | | | Summary: New base class for all future SMT sorts. The only change is that the class implements methods `isBooleanSort()`, `isBitvectorSort()` and `isFloatSort()` so it doesn't rely on `Z3`'s enum. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49550 llvm-svn: 337916
* [analyzer] Create generic SMT Context classMikhail R. Gadelha2018-07-251-0/+30
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch creates `SMTContext` which will wrap a specific SMT context, through `SMTSolverContext`. The templated `SMTSolverContext` class it's a simple wrapper around a SMT specific context (currently only used in the Z3 backend), while `Z3Context` inherits `SMTSolverContext<Z3_context>` and implements solver specific operations like initialization and destruction of the context. This separation was done because: 1. We might want to keep one single context, shared across different `SMTConstraintManager`s. It can be achieved by constructing a `SMTContext`, through a function like `CreateSMTContext(Z3)`, `CreateSMTContext(BOOLECTOR)`, etc. The rest of the CSA only need to know about `SMTContext`, so maybe it's a good idea moving `SMTSolverContext` to a separate header in the future. 2. Any generic SMT operation will only require one `SMTSolverContext`object, which can access the specific context by calling `getContext()`. Reviewers: NoQ, george.karpenkov Reviewed By: george.karpenkov Subscribers: xazax.hun, szepet, a.sidorin Differential Revision: https://reviews.llvm.org/D49233 llvm-svn: 337914
* [clang-format ]Extend IncludeCategories regex documentationKrasimir Georgiev2018-07-252-1/+7
| | | | | | | | | | | | | | | | | | | Summary: Extend the Clang-Format IncludeCategories documentation by adding a link to the supported regular expression standard (POSIX). And extenting the example with a system header regex. [[ https://bugs.llvm.org/show_bug.cgi?id=35041 | bug 35041]] Contributed by WimLeflere! Reviewers: krasimir, Typz Reviewed By: krasimir Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D48827 llvm-svn: 337899
* [analyzer] Syntactic matcher for leaks associated with run loop and ↵George Karpenkov2018-07-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | autoreleasepool A checker for detecting leaks resulting from allocating temporary autoreleasing objects before starting the main run loop. Checks for two antipatterns: 1. ObjCMessageExpr followed by [[NARunLoop mainRunLoop] run] in the same autorelease pool. 2. ObjCMessageExpr followed by [[NARunLoop mainRunLoop] run] in no autorelease pool. Happens-before relationship is modeled purely syntactically. rdar://39299145 Differential Revision: https://reviews.llvm.org/D49528 llvm-svn: 337876
* [Sema] Destroy tokens in DeclaratorChunk paramsBenjamin Kramer2018-07-241-2/+1
| | | | | | Otherwise this leaks in some edge cases. llvm-svn: 337862
* Revert "[VFS] Cleanups to VFS interfaces."Jordan Rupprecht2018-07-241-15/+12
| | | | | | This reverts commit r337834 due to test failures. llvm-svn: 337850
* [VFS] Cleanups to VFS interfaces.Sam McCall2018-07-241-12/+15
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: - add comments clarifying semantics - Status::copyWithNewName(Status, Name) --> instance method - Status::copyWithNewName(fs::file_status, Name) --> constructor (it's not a copy) - File::getName() -> getRealPath(), reflecting its actual behavior/function and stop returning status().getName() in the base class (callers can do this fallback if they want to, it complicates the contracts). This is mostly NFC, but the behavior of File::getName() affects FileManager's FileEntry::tryGetRealPathName(), which now fails in more cases: - non-real file cases - real-file cases where the underlying vfs::File was opened in a way that doesn't call realpath(). (In these cases we don't know a distinct real name, so in principle it seems OK) Reviewers: klimek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D49724 llvm-svn: 337834
* [Sema] Mark implicitly-inserted ICE's as being part of explicit cast (PR38166)Roman Lebedev2018-07-242-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As discussed in [[ https://bugs.llvm.org/show_bug.cgi?id=38166 | PR38166 ]], we need to be able to distinqush whether the cast we are visiting is actually a cast, or part of an `ExplicitCast`. There are at least four ways to get there: 1. Introduce a new `CastKind`, and use it instead of `IntegralCast` if we are in `ExplicitCast`. Would work, but does not scale - what if we will need more of these cast kinds? 2. Introduce a flag in `CastExprBits`, whether this cast is part of `ExplicitCast` or not. Would work, but it isn't immediately clear where it needs to be set. 2. Fix `ScalarExprEmitter::VisitCastExpr()` to visit these `NoOp` casts. As pointed out by @rsmith, CodeGenFunction::EmitMaterializeTemporaryExpr calls skipRValueSubobjectAdjustments, which steps over the CK_NoOp cast`, which explains why we currently don't visit those. This is probably impossible, as @efriedma points out, that is intentional as per `[class.temporary]` in the standard 3. And the simplest one, just record which NoOp casts we skip. It just kinda works as-is afterwards. But, the approach with a flag is the least intrusive one, and is probably the best one overall. Reviewers: rsmith, rjmccall, majnemer, efriedma Reviewed By: rsmith Subscribers: cfe-commits, aaron.ballman, vsk, llvm-commits, rsmith Differential Revision: https://reviews.llvm.org/D49508 llvm-svn: 337815
* Warn if a local variable's initializer retains a pointer/reference to aRichard Smith2018-07-242-16/+27
| | | | | | non-lifetime-extended temporary object. llvm-svn: 337790
OpenPOWER on IntegriCloud