summaryrefslogtreecommitdiffstats
path: root/llvm/docs
Commit message (Collapse)AuthorAgeFilesLines
* Bump minimum toolchain versionJF Bastien2019-02-072-17/+33
| | | | | | | | | | | | | | | Summary: The RFC on moving past C++11 got good traction: http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html This patch therefore bumps the toolchain versions according to our policy: llvm.org/docs/DeveloperPolicy.html#toolchain Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane Differential Revision: https://reviews.llvm.org/D57264 llvm-svn: 353374
* [ADT] Add a fallible_iterator wrapper.Lang Hames2019-02-051-11/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A fallible iterator is one whose increment or decrement operations may fail. This would usually be supported by replacing the ++ and -- operators with methods that return error: class MyFallibleIterator { public: // ... Error inc(); Errro dec(); // ... }; The downside of this style is that it no longer conforms to the C++ iterator concept, and can not make use of standard algorithms and features such as range-based for loops. The fallible_iterator wrapper takes an iterator written in the style above and adapts it to (mostly) conform with the C++ iterator concept. It does this by providing standard ++ and -- operator implementations, returning any errors generated via a side channel (an Error reference passed into the wrapper at construction time), and immediately jumping the iterator to a known 'end' value upon error. It also marks the Error as checked any time an iterator is compared with a known end value and found to be inequal, allowing early exit from loops without redundant error checking*. Usage looks like: MyFallibleIterator I = ..., E = ...; Error Err = Error::success(); for (auto &Elem : make_fallible_range(I, E, Err)) { // Loop body is only entered when safe. // Early exits from loop body permitted without checking Err. if (SomeCondition) return; } if (Err) // Handle error. * Since failure causes a fallible iterator to jump to end, testing that a fallible iterator is not an end value implicitly verifies that the error is a success value, and so is equivalent to an error check. Reviewers: dblaikie, rupprecht Subscribers: mgorny, dexonsmith, kristina, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57618 llvm-svn: 353237
* [Intrinsic] Unsigned Fixed Point Multiplication IntrinsicLeonard Chan2019-02-041-2/+62
| | | | | | | | | | | | | Add an intrinsic that takes 2 unsigned integers with the scale of them provided as the third argument and performs fixed point multiplication on them. This is a part of implementing fixed point arithmetic in clang where some of the more complex operations will be implemented as intrinsics. Differential Revision: https://reviews.llvm.org/D55625 llvm-svn: 353059
* [llvm-exegesis] Don't default to running&dumping all analyses to '-'Roman Lebedev2019-02-041-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Up until the point i have looked in the source, i didn't even understood that i can disable 'cluster' output. I have always silenced it via ` &> /dev/null`. (And hoped it wasn't contributing much of the run time.) While i expect that it has it's use-cases i never once needed it so far. If i forget to silence it, console is completely flooded with that output. How about not expecting users to opt-out of analyses, but to explicitly specify the analyses that should be performed? Reviewers: courbet, gchatelet Reviewed By: courbet Subscribers: tschuett, RKSimon, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57648 llvm-svn: 353021
* [docs] Recommend assertions when testing.Davide Italiano2019-02-031-1/+1
| | | | | | Pointed out by Shoaib Meenai. llvm-svn: 353008
* Revert "Bump minimum toolchain version"JF Bastien2019-02-022-33/+17
| | | | | | | | | | | Reverting D57264 again, it looks like we're down to two bots that need fixing: polly-amd64-linux polly-arm-linux They both have old versions of libstdc++ and recent clang. llvm-svn: 352954
* Bump minimum toolchain versionJF Bastien2019-02-022-17/+33
| | | | | | | | | | | | | | | Summary: The RFC on moving past C++11 got good traction: http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html This patch therefore bumps the toolchain versions according to our policy: llvm.org/docs/DeveloperPolicy.html#toolchain Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane Differential Revision: https://reviews.llvm.org/D57264 llvm-svn: 352951
* Hopefully fix a couple more sphinx doc errors.James Y Knight2019-02-011-2/+10
| | | | | | | These seem to only appear on the buildbot runner, and it looks like we tried to suppress them, but it's not working. Not sure why. llvm-svn: 352903
* Fix some sphinx doc errors.James Y Knight2019-02-011-0/+2
| | | | llvm-svn: 352887
* [doc]Update String Error documentation in Programmer ManualJames Henderson2019-02-011-4/+14
| | | | | | | | | | | | | A while back, createStringError was added to provide easier construction of StringError instances, especially with formatting options. Prior to this patch, that the documentation only mentions the standard method of using it. Since createStringError is slightly shorter to type, and also provides the formatting options, this patch updates the Programmer's Manual to use the new function in its examples, and to mention the printf formatting options. It also fixes a small typo in one of the examples and removes the unnecessary make_error_code call. llvm-svn: 352846
* Revert "Bump minimum toolchain version"JF Bastien2019-02-012-33/+17
| | | | | | Looks like we still have a few bots that are sad. Let try to get them fixed! llvm-svn: 352835
* Bump minimum toolchain versionJF Bastien2019-02-012-17/+33
| | | | | | | | | | | | | | | Summary: The RFC on moving past C++11 got good traction: http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html This patch therefore bumps the toolchain versions according to our policy: llvm.org/docs/DeveloperPolicy.html#toolchain Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane Differential Revision: https://reviews.llvm.org/D57264 llvm-svn: 352834
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-011-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc doesn't choke on it, hopefully. Original Message: The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352827
* Revert "Bump minimum toolchain version"JF Bastien2019-01-312-33/+17
| | | | | | | | A handful of bots are still breaking, either because I missed them in my audit, they were offline, or something else. I'm contacting their authors, but I'll revert for now and re-commit later. llvm-svn: 352814
* DeveloperPolicy: update toolchain with sample RFC / patchJF Bastien2019-01-311-0/+3
| | | | | | As was suggested when the policy originally went in. llvm-svn: 352812
* Bump minimum toolchain versionJF Bastien2019-01-312-17/+33
| | | | | | | | | | | | | | | Summary: The RFC on moving past C++11 got good traction: http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html This patch therefore bumps the toolchain versions according to our policy: llvm.org/docs/DeveloperPolicy.html#toolchain Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, mehdi_amini, jyknight, rsmith, chandlerc, smeenai, hans, reames, lattner, lhames, erichkeane Differential Revision: https://reviews.llvm.org/D57264 llvm-svn: 352811
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-311-11/+5
| | | | | | | | | This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791). Seems to run into compilation failures with GCC (but not clang, where I tested it). Reverting while I investigate. llvm-svn: 352800
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-01-311-5/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352791
* [libFuzzer] update docsKostya Serebryany2019-01-311-5/+6
| | | | llvm-svn: 352715
* Add a 'dynamic' parameter to the objectsize intrinsicErik Pilkington2019-01-301-19/+19
| | | | | | | | | | | | | | This is meant to be used with clang's __builtin_dynamic_object_size. When 'true' is passed to this parameter, the intrinsic has the potential to be folded into instructions that will be evaluated at run time. When 'false', the objectsize intrinsic behaviour is unchanged. rdar://32212419 Differential revision: https://reviews.llvm.org/D56761 llvm-svn: 352664
* [llvm-exegesis] Add throughput mode.Clement Courbet2019-01-301-8/+10
| | | | | | | | | | | | | | | | Summary: This just uses the latency benchmark runner on the parallel uops snippet generator. Fixes PR37698. Reviewers: gchatelet Subscribers: tschuett, RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D57000 llvm-svn: 352632
* [docs] Prevent O0 optnone for opt inputShoaib Meenai2019-01-291-2/+2
| | | | | | | | | | If we just compile with -O0, clang will add optnone attributes everywhere, so opt won't actually be able to perform any passes. Instruct clang to not emit the optnone so opt can do its thing. Differential Revision: https://reviews.llvm.org/D56950 llvm-svn: 352550
* Adjust documentation for git migration.James Y Knight2019-01-295-17/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes most references to the paths: llvm.org/svn/ llvm.org/git/ llvm.org/viewvc/ github.com/llvm-mirror/ github.com/llvm-project/ reviews.llvm.org/diffusion/ to instead point to https://github.com/llvm/llvm-project. This is *not* a trivial substitution, because additionally, all the checkout instructions had to be migrated to instruct users on how to use the monorepo layout, setting LLVM_ENABLE_PROJECTS instead of checking out various projects into various subdirectories. I've attempted to not change any scripts here, only documentation. The scripts will have to be addressed separately. Additionally, I've deleted one document which appeared to be outdated and unneeded: lldb/docs/building-with-debug-llvm.txt Differential Revision: https://reviews.llvm.org/D57330 llvm-svn: 352514
* [llvm-symbolizer][doc] Tweak wording of --adjust-vma switch descriptionJames Henderson2019-01-291-2/+1
| | | | | | The address isn't dynamically relocated. The object is. llvm-svn: 352477
* [docs] Fix a couple spelling errors.Eli Friedman2019-01-282-2/+2
| | | | llvm-svn: 352439
* [LangRef] Mention vector support for bitreverse/bswap intrinsics (PR38012)Simon Pilgrim2019-01-281-8/+12
| | | | | | Differential Revision: https://reviews.llvm.org/D57309 llvm-svn: 352386
* [TblGen][NFC] Fix documentation formattingJaved Absar2019-01-251-7/+3
| | | | llvm-svn: 352212
* [llvm-symbolizer] Add switch to adjust addresses by fixed offsetJames Henderson2019-01-251-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | If a stack trace or similar has a list of addresses from an executable or DSO loaded at a variable address (e.g. due to ASLR), the addresses will not directly correspond to the addresses stored in the object file. If a user wishes to use llvm-symbolizer, they have to subtract the load address from every address. This is somewhat inconvenient, especially as the output of --print-address will result in the adjusted address being listed, rather than the address coming from the stack trace, making it harder to map results between the two. This change adds a new switch to llvm-symbolizer --adjust-vma which takes an offset, which is then used to automatically do this calculation. The printed address remains the input address (allowing for easy mapping), whilst the specified offset is applied to the addresses when performing the lookup. The switch is conceptually similar to llvm-objdump's new switch of the same name (see D57051), which in turn mirrors a GNU switch. There is no equivalent switch in addr2line. Reviewed by: grimar Differential Revision: https://reviews.llvm.org/D57151 llvm-svn: 352195
* [TblGen] Extend !if semantics through new feature !condJaved Absar2019-01-252-1/+23
| | | | | | | | | | | | | | | | | This patch extends TableGen language with !cond operator. Instead of embedding !if inside !if which can get cumbersome, one can now use !cond. Below is an example to convert an integer 'x' into a string: !cond(!lt(x,0) : "Negative", !eq(x,0) : "Zero", !eq(x,1) : "One, 1 : "MoreThanOne") Reviewed By: hfinkel, simon_tatham, greened Differential Revision: https://reviews.llvm.org/D55758 llvm-svn: 352185
* Revert "[Sanitizers] UBSan unreachable incompatible with ASan in the ↵Julian Lettner2019-01-241-4/+0
| | | | | | | | presence of `noreturn` calls" This reverts commit cea84ab93aeb079a358ab1c8aeba6d9140ef8b47. llvm-svn: 352069
* [Docs] Add information about unit tests to the testing guideMichael Platings2019-01-241-10/+25
| | | | | | Differential Revision: https://reviews.llvm.org/D57088 llvm-svn: 352052
* [docs] Remove extra character from git URL in Getting Started guide.Douglas Yung2019-01-241-1/+1
| | | | llvm-svn: 352005
* [Sanitizers] UBSan unreachable incompatible with ASan in the presence of ↵Julian Lettner2019-01-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `noreturn` calls Summary: UBSan wants to detect when unreachable code is actually reached, so it adds instrumentation before every `unreachable` instruction. However, the optimizer will remove code after calls to functions marked with `noreturn`. To avoid this UBSan removes `noreturn` from both the call instruction as well as from the function itself. Unfortunately, ASan relies on this annotation to unpoison the stack by inserting calls to `_asan_handle_no_return` before `noreturn` functions. This is important for functions that do not return but access the the stack memory, e.g., unwinder functions *like* `longjmp` (`longjmp` itself is actually "double-proofed" via its interceptor). The result is that when ASan and UBSan are combined, the `noreturn` attributes are missing and ASan cannot unpoison the stack, so it has false positives when stack unwinding is used. Changes: # UBSan now adds the `expect_noreturn` attribute whenever it removes the `noreturn` attribute from a function # ASan additionally checks for the presence of this attribute Generated code: ``` call void @__asan_handle_no_return // Additionally inserted to avoid false positives call void @longjmp call void @__asan_handle_no_return call void @__ubsan_handle_builtin_unreachable unreachable ``` The second call to `__asan_handle_no_return` is redundant. This will be cleaned up in a follow-up patch. rdar://problem/40723397 Reviewers: delcypher, eugenis Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D56624 llvm-svn: 352003
* [llvm-symbolizer] Add support for -i and -inlines as aliases for -inliningDouglas Yung2019-01-241-1/+1
| | | | | | | | | | | | | | This change adds two options, -i and -inlines as aliases for the -inlining option to llvm-symbolizer to improve compatibility with the GNU addr2line utility which accepts these options. It also modifies existing tests that use -inlining to exercise these new aliases as well. This fixes PR40073. Reviewed by: jhenderson, Quolyk, ruiu Differential Revision: https://reviews.llvm.org/D57083 llvm-svn: 351999
* [llvm-symbolizer] Improve compatibility of --functions with GNU addr2lineJames Henderson2019-01-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This fixes https://bugs.llvm.org/show_bug.cgi?id=40072. GNU addr2line's --functions switch is off by default, has a short alias of -f, and does not take an argument. This patch changes llvm-symbolizer to allow the second and third point (changing the default behaviour may have negative impacts on users). If the option is missing a value, it now treats it as "linkage". This change does cause one previously valid command-line to behave differently. Before --functions <value> was accepted, but now only --functions=<value> is allowed (as well as --functions). The old behaviour will result in the value being treated as a positional argument. The previous testing for --functions=short has been pulled out into a new test that also tests the other accepted values and option formats. Reviewed by: ruiu Differential Revision: https://reviews.llvm.org/D57049 llvm-svn: 351968
* [Docs] Add a note clarifying how to get good test performances.Davide Italiano2019-01-221-0/+7
| | | | | | Differential Revision: https://reviews.llvm.org/D56337 llvm-svn: 351885
* [FileCheck] Suppress old -v/-vv diags if dumping inputJoel E. Denny2019-01-221-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old diagnostic form of the trace produced by -v and -vv looks like: ``` check1:1:8: remark: CHECK: expected string found in input CHECK: abc ^ <stdin>:1:3: note: found here ; abc def ^~~ ``` When dumping annotated input is requested (via -dump-input), I find that this old trace is not useful and is sometimes harmful: 1. The old trace is mostly redundant because the same basic information also appears in the input dump's annotations. 2. The old trace buries any error diagnostic between it and the input dump, but I find it useful to see any error diagnostic up front. 3. FILECHECK_OPTS=-dump-input=fail requests annotated input dumps only for failed FileCheck calls. However, I have to also add -v or -vv to get a full set of annotations, and that can produce massive output from all FileCheck calls in all tests. That's a real problem when I run this in the IDE I use, which grinds to a halt as it tries to capture all that output. When -dump-input=fail|always, this patch suppresses the old trace from -v or -vv. Error diagnostics still print as usual. If you want the old trace, perhaps to see variable expansions, you can set -dump-input=none (the default). Reviewed By: probinson Differential Revision: https://reviews.llvm.org/D55825 llvm-svn: 351881
* Reapply "IR: Add fp operations to atomicrmw"Matt Arsenault2019-01-221-4/+9
| | | | | | | This reapplies commits r351778 and r351782 with RISCV test fixes. llvm-svn: 351850
* [docs] Scudo: document error messages & their potential causeKostya Kortchinsky2019-01-221-3/+53
| | | | | | | | | | | | | | | | | | Summary: A couple of changes in the Scudo documentation: - tag the shell code blocks as `console`; - document error messages that are displayed in some termination conditions, the reason they triggered, and potential causes. Reviewers: eugenis, enh Reviewed By: eugenis Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D56857 llvm-svn: 351838
* Add DIGlobalVariableExpression to LangRefAdrian Prantl2019-01-221-6/+29
| | | | llvm-svn: 351837
* Revert r351778: IR: Add fp operations to atomicrmwChandler Carruth2019-01-221-9/+4
| | | | | | | | | | | | | This broke the RISCV build, and even with that fixed, one of the RISCV tests behaves surprisingly differently with asserts than without, leaving there no clear test pattern to use. Generally it seems bad for hte IR to differ substantially due to asserts (as in, an alloca is used with asserts that isn't needed without!) and nothing I did simply would fix it so I'm reverting back to green. This also required reverting the RISCV build fix in r351782. llvm-svn: 351796
* [llvm-symbolizer] Add support for --basenames/-sJames Henderson2019-01-221-0/+4
| | | | | | | | | | | | | This fixes https://bugs.llvm.org/show_bug.cgi?id=40068. --basenames is a GNU addr2line switch which strips the directory names from the file path in the output. Reviewed by: ruiu Differential Revision: https://reviews.llvm.org/D56919 llvm-svn: 351795
* IR: Add fp operations to atomicrmwMatt Arsenault2019-01-221-4/+9
| | | | | | Add just fadd/fsub for now. llvm-svn: 351778
* [LangRef] Clarify semantics of volatile operations.Eli Friedman2019-01-221-0/+18
| | | | | | | | | | | | | | | | | | Specifically, clarify the following: 1. Volatile load and store may access addresses that are not memory. 2. Volatile load and store do not modify arbitrary memory. 3. Volatile load and store do not trap. Prompted by recent volatile discussion on llvmdev. Currently, there's sort of a split in the source code about whether volatile operations are allowed to trap; this resolves that dispute in favor of not allowing them to trap. Differential Revision: https://reviews.llvm.org/D53184 llvm-svn: 351772
* Document toolchain update policyJF Bastien2019-01-212-8/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Capture the current agreed-upon toolchain update policy based on the following discussions: - LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond!" llvm.org/devmtg/2018-10/talk-abstracts.html#bof3 - A Short Policy Proposal Regarding Host Compilers lists.llvm.org/pipermail/llvm-dev/2018-May/123238.html - Using C++14 code in LLVM (2018) lists.llvm.org/pipermail/llvm-dev/2018-May/123182.html - Using C++14 code in LLVM (2017) lists.llvm.org/pipermail/llvm-dev/2017-October/118673.html - Using C++14 code in LLVM (2016) lists.llvm.org/pipermail/llvm-dev/2016-October/105483.html - Document and Enforce new Host Compiler Policy llvm.org/D47073 - Require GCC 5.1 and LLVM 3.5 at a minimum llvm.org/D46723 Subscribers: jkorous, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D56819 llvm-svn: 351765
* [llvm-symbolizer] Add -no-demangle as alias for -demangle=falseDmitry Venikov2019-01-211-0/+4
| | | | | | | | | | | | | | Summary: Provides -no-demangle as alias for -demangle=false. Motivation: https://bugs.llvm.org/show_bug.cgi?id=40075 Reviewers: jhenderson, ruiu Reviewed By: jhenderson Subscribers: erik.pilkington, rupprecht, llvm-commits Differential Revision: https://reviews.llvm.org/D56773 llvm-svn: 351735
* Fix typos throughout the license files that somehow I and my reviewersChandler Carruth2019-01-211-0/+1
| | | | | | | | | | | all missed! Thanks to Alex Bradbury for pointing this out, and the fact that I never added the intended `legacy` anchor to the developer policy. Add that anchor too. With hope, this will cause the links to all resolve successfully. llvm-svn: 351731
* Replace llvm::isPodLike<...> by llvm::is_trivially_copyable<...>Serge Guelton2019-01-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for isPodLike<std::pair<...>> did not match the expectation of std::is_trivially_copyable which makes the memcpy optimization invalid. This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable. Unfortunately std::is_trivially_copyable is not portable across compiler / STL versions. So a portable version is provided too. Note that the following specialization were invalid: std::pair<T0, T1> llvm::Optional<T> Tests have been added to assert that former specialization are respected by the standard usage of llvm::is_trivially_copyable, and that when a decent version of std::is_trivially_copyable is available, llvm::is_trivially_copyable is compared to std::is_trivially_copyable. As of this patch, llvm::Optional is no longer considered trivially copyable, even if T is. This is to be fixed in a later patch, as it has impact on a long-running bug (see r347004) Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296. Differential Revision: https://reviews.llvm.org/D54472 llvm-svn: 351701
* Update the coding standards with the new file header.Chandler Carruth2019-01-191-4/+3
| | | | llvm-svn: 351652
* [NFX] Fix language reference title declarationJohannes Doerfert2019-01-191-1/+1
| | | | llvm-svn: 351644
OpenPOWER on IntegriCloud