| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
coding standards, and instead fix the existing section.
Thanks to Daniel Jasper for pointing out we already had a section
devoted to this topic. Instead of adding sections, just hack on this
section some. Also fix the example in the anonymous namespace section
below it to agree with the new advice.
As a re-cap, this switches the LLVM preferred style to never indent
namespaces. Having two approaches just led to endless (and utterly
pointless) debates about what was "small enough". This wasn't helping
anyone. The no-indent rule is easy to understand and doesn't really make
anything harder to read. Moreover, with tools like clang-format it is
considerably nicer to have simple consistent rules.
llvm-svn: 199637
|
| |
|
|
|
|
|
|
|
|
|
| |
(and to mention namespace ending comments). This is based on a quick
discussion on the developer mailing list where there was essentially no
objections to a simple and consistent rule. This should avoid future
debates about whether or not a namespace is "big enough" to indent. It
also matches clang-format's current behavior with LLVM source code which
hasn't really seen any opposition in code reviews that I spot checked.
llvm-svn: 199620
|
| |
|
|
|
|
|
| |
This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities and contractions in nearby lines.
llvm-svn: 196471
|
| |
|
|
|
|
| |
This is under active discussion.
llvm-svn: 189730
|
| |
|
|
|
|
|
| |
implementation files. While doc generation systems don't need this,
humans do benefit from it. Not everyone reads all code through doxygen.
llvm-svn: 189704
|
| |
|
|
| |
llvm-svn: 187902
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
definition
Current practice is not to use 'inline' in:
class Foo {
public:
inline void bar() {
// ...
}
};
llvm-svn: 174317
|
| |
|
|
| |
llvm-svn: 173103
|
| |
|
|
|
|
|
|
|
| |
Before we learned about :doc:, we used :ref: and put a dummy link at the
top of each page. Don't do that anymore.
This fixes PR14891 as a special case.
llvm-svn: 172162
|
| |
|
|
|
|
|
| |
trivially achievable with an editor. I'll likely check in a silly python
script to help with this too.
llvm-svn: 169107
|
| |
|
|
|
|
| |
Some variables in code examples were not LikeThis.
llvm-svn: 168275
|
| |
|
|
| |
llvm-svn: 168271
|
| |
|
|
| |
llvm-svn: 166821
|
| |
|
|
|
|
|
|
| |
obvious stuff and most new code being committed conforms to that. Some old
code does not; this might cause confusion and this is the motivation to
document the correct guidelines.
llvm-svn: 166378
|
| |
|
|
| |
llvm-svn: 164964
|
| |
|
|
| |
llvm-svn: 164920
|
| |
|
|
|
|
| |
Wordsmithing by Matt Beaumont-Gay in response to r164389.
llvm-svn: 164395
|
| |
|
|
| |
llvm-svn: 164389
|
| |
|
|
| |
llvm-svn: 164311
|
| |
|
|
|
|
| |
Try not to violate conventions immediately before explaining them.
llvm-svn: 164278
|
| |
|
|
| |
llvm-svn: 164126
|
| |
|
|
| |
llvm-svn: 164101
|
| |
|
|
| |
llvm-svn: 158880
|
| |
|
|
| |
llvm-svn: 158877
|
|
|
llvm-svn: 158786
|