| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Patch by Doug Gregor, Tres Popp, and Dmitri Gribenko.
Reviewers: chandlerc
Subscribers: hfinkel, bmcreusillet, arsenm, doug.gregor, mgrang, arphaman, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D69354
|
|
|
|
| |
(And test my commit access. We're working on larger changes here.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I just bumped the minimum compiler versions to support C++14 in D66188.
Following [our process](http://llvm.org/docs/DeveloperPolicy.html#toolchain) and [our previous agreement](http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html), I'm now officially bumping the C++ version to 14 and updating the documentation.
Subscribers: mgorny, jkorous, dexonsmith, llvm-commits, chandlerc, thakis, EricWF, jyknight, lhames, JDevlieghere
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D66195
llvm-svn: 368887
|
|
|
|
| |
llvm-svn: 351652
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D54446
llvm-svn: 346861
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a bit awkward in a handful of places where we didn't even have
an instruction and now we have to see if we can build one. But on the
whole, this seems like a win and at worst a reasonable cost for removing
`TerminatorInst`.
All of this is part of the removal of `TerminatorInst` from the
`Instruction` type hierarchy.
llvm-svn: 340701
|
|
|
|
|
|
|
|
| |
whitespace.
Clarify that you should not introduce trailing whitespace when making a commit and that you should not remove trailing whitespace that's unrelated to code you are changing or are about to change. Then clarified the developer policy around what is considered an obvious whitespace commit.
llvm-svn: 339455
|
|
|
|
|
|
| |
Update one link which redirected, and remove an Amazon ref.
llvm-svn: 332735
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: RKSimon, t.p.northover, dexonsmith
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45831
llvm-svn: 330773
|
|
|
|
| |
llvm-svn: 329277
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(I suppose these two pieces could be separated - but seemed related
enough)
As discussed on llvm-dev, this documents the general expectation of how
library layering should be handled. There are a few existing cases where
these constraints are not met, but as with most style guide things -
this is forward looking and provides guidance when cleaning up existing
code, it doesn't immediately require that all previous code be cleaned
up to match. (see: naming conventions, etc)
Differential Revision: https://reviews.llvm.org/D42771
llvm-svn: 324004
|
|
|
|
| |
llvm-svn: 318115
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Beware of non-determinism due to ordering of pointers
Reviewers: dblaikie, dexonsmith
Reviewed By: dblaikie
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D37525
llvm-svn: 312667
|
|
|
|
|
|
|
|
|
|
|
|
| |
The CodingStandards section on avoiding the re-evaluation of end() hasn't been
updated since range-based for loops were adopted in the LLVM codebase. This
patch adds a very brief section that documents how range-based for loops
should be used wherever possible. It also moves example code in
CodingStandards to use range-based for loops and auto when appropriate.
Differential Revision: https://reviews.llvm.org/D37264
llvm-svn: 312236
|
|
|
|
|
|
|
|
|
| |
Use text suggested by Justin Bogner in post-commit review of r311146
<http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20170814/479898.html>,
which makes it clear that report_fatal_error shouldn't be used when there is a
practicable alternative. Also make this clearer in CodingStandards.
llvm-svn: 311147
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ProgrammersManual.rst
The current ProgrammersManual.rst document has a lot of well-written
documentation on error handling thanks to @lhames. It suggests errors can be
split cleanly into "programmatic" and "recoverable" errors. However, the
reality in current LLVM seems to be there are a number of cases where a
non-programmatic error is not easily recoverable. Therefore, add a note to
indicate the existence of report_fatal_error for these cases. I've also added
a reminder to CodingStandards.rst in the section on assertions, to indicate
that llvm_unreachable and assertions should not be relied upon to report
errors triggered by user input.
The ProgrammersManual is also silent on the use of LLVMContext::diagnose,
which is used in BPF+WebAssembly+AMDGPU to report some errors during
instruction selection. I don't address that in this patch, as it's not quite
clear how to fit in to the current error handling story
Differential Revision: https://reviews.llvm.org/D36826
llvm-svn: 311146
|
|
|
|
| |
llvm-svn: 308331
|
|
|
|
|
|
|
|
| |
MSVC 2015 has been the minimum supported version of VS since October.
Differential Revision: https://reviews.llvm.org/D25710
llvm-svn: 289854
|
|
|
|
|
|
|
|
|
|
| |
Mailing list discussion about this:
http://lists.llvm.org/pipermail/llvm-dev/2016-September/104631.html
Code changes to simplify the ifdefs will come next, and can be reverted
without affecting the policy if someone needs it.
llvm-svn: 284660
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The RFC proposal sent to increase the minimum required GCC version
to 4.8 received a lot of support. See the following thread:
http://lists.llvm.org/pipermail/llvm-dev/2016-October/105955.html,
This patch implements that by updating the docs. I believe the
references to libstdc++ 4.7 issues can be removed as well, please
let me know if that is not the case or if they should be updated
a different way.
Reviewers: rengolin
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D25683
llvm-svn: 284497
|
|
|
|
| |
llvm-svn: 284380
|
|
|
|
| |
llvm-svn: 282490
|
|
|
|
|
|
|
|
|
|
|
| |
auto-brief format for doxygen comments. Most notable is switching to
that in the example doxygen comment. I've also tweaked the wording but
am happy to tweak it further if others have suggestions here.
Mostly doing this to capture something I and others have been writing
consistently and repeatedly in code reviews.
llvm-svn: 280419
|
|
|
|
|
|
|
| |
Reviewed By: lattner
Differential Revision: https://reviews.llvm.org/D23591
llvm-svn: 279560
|
|
|
|
|
|
|
|
|
| |
The statement on using #if 0 ... #endif is not very clear (for people like me
:-)). This patch clarifies it a bit to avoid confusion.
Differential Revision: https://reviews.llvm.org/D23404
llvm-svn: 278932
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
algorithms,
such as std::equal on the third argument. This reverts previous workarounds.
Predefining _DEBUG_POINTER_IMPL disables Visual C++ 2013 headers from defining
it to a function performing the null pointer check. In practice, it's not that
bad since any function actually using the nullptr will seg fault. The other
iterator sanity checks remain enabled in the headers.
Reviewed by Aaron Ballmanþ and Duncan P. N. Exon Smith.
llvm-svn: 245711
|
|
|
|
| |
llvm-svn: 245473
|
|
|
|
| |
llvm-svn: 243999
|
|
|
|
| |
llvm-svn: 237417
|
|
|
|
|
|
|
| |
Use them in WinEHPrepare so that we can spot any toolchain bugs that
come up.
llvm-svn: 236244
|
|
|
|
|
|
| |
Delegating constructors seem to work fine with all supported compilers.
llvm-svn: 231473
|
|
|
|
|
|
| |
required version, we can move that to the list of acceptable C++11 features.
llvm-svn: 231313
|
|
|
|
|
|
|
|
|
| |
It didn't seem worth leaving behind a guideline to use '= delete' to
make a class uncopyable. That's a well known C++ design pattern.
Reported on the mailing list and in PR22724.
llvm-svn: 230776
|
|
|
|
| |
llvm-svn: 230510
|
|
|
|
|
|
| |
allowed now.
llvm-svn: 229369
|
|
|
|
|
|
|
|
| |
guarded by it.
We no longer support compilers without variadic template support.
llvm-svn: 229324
|
|
|
|
| |
llvm-svn: 229323
|
|
|
|
| |
llvm-svn: 226750
|
|
|
|
|
|
|
|
|
| |
Rather than define our own standards, we adopt a set of best practices that
are already in use by the Go community.
Differential Revision: http://reviews.llvm.org/D5761
llvm-svn: 219646
|
|
|
|
|
|
|
| |
I should have included this as part of r215986, which worked around this
corner by changing ArrayRef::equals() not to use std::equal. Alas.
llvm-svn: 215988
|
|
|
|
|
|
|
|
| |
Clang-cl supports MSVC-style RTTI now, and we can even compile
typeid(...) with /GR-. Just don't instantiate std::function with a
polymorphic type, or bad things will happen.
llvm-svn: 212148
|
|
|
|
|
|
| |
coding standard suggesting using it instead of the (unavailable) std::function.
llvm-svn: 208067
|
|
|
|
| |
llvm-svn: 208034
|
|
|
|
|
|
| |
which GCC detects and Clang does not!
llvm-svn: 208033
|
|
|
|
| |
llvm-svn: 206481
|
|
|
|
| |
llvm-svn: 206480
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
:doc:`...` and :ref:`...` links help Sphinx keep track the dependencies
between documents and ensure that they are not pointing to nowhere.
Raw HTML links work just fine and are easier for people less familiar
with reST/Sphinx. They are easy to change over to the :doc:/:ref: style
after the fact so this is not a problem.
This commit doesn't fix all of them.
llvm-svn: 205792
|
|
|
|
|
|
| |
Using const is orthogonal to guidelines on using auto& and auto*.
llvm-svn: 203257
|
|
|
|
| |
llvm-svn: 203254
|
|
|
|
|
|
|
|
|
| |
We'd like to keep the clang-cl self-host working until we implement
MSVC-compatible RTTI.
Differential Revision: http://llvm-reviews.chandlerc.com/D2930
llvm-svn: 202758
|