[Docs] Clarify the guideline on omitting braces

While working on a clang-format option RemoveBracesLLVM that removes
braces following the guideline, we were unsure about what to do with
the braces o

[Docs] Clarify the guideline on omitting braces

While working on a clang-format option RemoveBracesLLVM that removes
braces following the guideline, we were unsure about what to do with
the braces of do-while loops. The ratio of using to omitting the
braces is about 4:1 in the llvm-project source, so it will help to
add an example to the guideline.

Also cleans up the original examples including making the nested if
example more targeted on avoiding potential dangling else situations.

Differential Revision: https://reviews.llvm.org/D126512

show more ...

Fix "the the" typo in documentation and user facing strings

There are many more instances of this pattern, but I chose to limit this change to .rst files (docs), anything in libcxx/include, and stri

Fix "the the" typo in documentation and user facing strings

There are many more instances of this pattern, but I chose to limit this change to .rst files (docs), anything in libcxx/include, and string literals. These have the highest chance of being seen by end users.

Reviewed By: #libc, Mordante, martong, ldionne

Differential Revision: https://reviews.llvm.org/D124708

show more ...

[doc] Fix namespace comment style in Coding Guidelines

The Coding Guidelines specify that the ending brace of a
namespace shall have a comment like:

} // end namespace clang

However the majority

[doc] Fix namespace comment style in Coding Guidelines

The Coding Guidelines specify that the ending brace of a
namespace shall have a comment like:

} // end namespace clang

However the majority of the code uses a different style:

} // namespace clang

Indeed:

$ git grep '// end' | wc -l
6724
$ git grep '// namespace' | wc -l
14348

Besides, this is the style enforced automatically by clang-format,
via the FixNamespaceComments option.

Having inconsistencies between the Coding Guidelines and the
code/tooling creates confusion, can lead to bikeshedding during
reviews and overall delays merging code. Therefore, update the
guidelines to reflect current usage. Updating legacy code to the
new standard should be done in a separate patch, if wanted.

Reviewed By: jyknight

Differential Revision: https://reviews.llvm.org/D115115

show more ...

[NFC] Trim trailing whitespace in *.rst

[docs] Fix broken link rendering in the LLVM Coding Standards.

Update references to 'master' branch.

This commit replace 'master' with 'main' in llvm/docs.

Reviewed By: sammccall, kristof.beyls

Differential Revision: https://reviews.llvm.org/D92831

llvmbuildectomy - replace llvm-build by plain cmake

No longer rely on an external tool to build the llvm component layout.

Instead, leverage the existing `add_llvm_componentlibrary` cmake function

llvmbuildectomy - replace llvm-build by plain cmake

No longer rely on an external tool to build the llvm component layout.

Instead, leverage the existing `add_llvm_componentlibrary` cmake function and
introduce `add_llvm_component_group` to accurately describe component behavior.

These function store extra properties in the created targets. These properties
are processed once all components are defined to resolve library dependencies
and produce the header expected by llvm-config.

Differential Revision: https://reviews.llvm.org/D90848

show more ...

[doc] Describe the header guard style

clang-tidy's llvm-header-guard rule references the LLVM style - where it's
missing.

Differential Revision: https://reviews.llvm.org/D84989

Clarify a bit the guideline on omitting braces, including more examples (NFC)

Like most readability rules, it isn't absolute and there is a matter of taste
to it. I think more recent part of the pro

Clarify a bit the guideline on omitting braces, including more examples (NFC)

Like most readability rules, it isn't absolute and there is a matter of taste
to it. I think more recent part of the project may be more consistent in the
current application of the guideline. I suspect sources like
mlir/lib/Dialect/StandardOps/IR/Ops.cpp may be examples of this at the moment.

Differential Revision: https://reviews.llvm.org/D82594

show more ...

[Docs] CodingStandards: for_each is discouraged

Summary:
As per disscussion in D83351, using `for_each` is potentially confusing,
at least in regards to inconsistent style (there's less than 100 `fo

[Docs] CodingStandards: for_each is discouraged

Summary:
As per disscussion in D83351, using `for_each` is potentially confusing,
at least in regards to inconsistent style (there's less than 100 `for_each`
usages in LLVM, but ~100.000 `for` range-based loops

Therefore, it should be avoided.

Reviewers: dblaikie, nickdesaulniers

Reviewed By: dblaikie, nickdesaulniers

Subscribers: hubert.reinterpretcast, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D83431

show more ...

[Docs] Add missing space, requested on c08ea07

Add to the Coding Standard our that single-line bodies omit braces

This is a rule that seems to have been enforced for the better part of
the decade, so we should document it for new contributors.

Add to the Coding Standard our that single-line bodies omit braces

This is a rule that seems to have been enforced for the better part of
the decade, so we should document it for new contributors.

Differential Revision: https://reviews.llvm.org/D80947

show more ...

[docs] Fix self-contradictory description of llvm_unreachable

Just two paragraphs above it says:
"If the compiler does not support this [skipping code generation for a particular branch], it will fa

[docs] Fix self-contradictory description of llvm_unreachable

Just two paragraphs above it says:
"If the compiler does not support this [skipping code generation for a particular branch], it will fall back
to the "abort" implementation."

And that actually correctly describes llvm_unreachable implementation.

Differential Revision: https://reviews.llvm.org/D81130

show more ...

[docs] Document coding standard for error and warning messages

In particular, these messages should start with a lower-case letter and
should have no trailing period at the end of the last sentence.

[docs] Document coding standard for error and warning messages

In particular, these messages should start with a lower-case letter and
should have no trailing period at the end of the last sentence.

See http://lists.llvm.org/pipermail/llvm-dev/2020-March/140178.html for
context.

Reviewed by: aaron.ballman, hubert.reinterpretcast, rnk, dblaikie

Differential Revision: https://reviews.llvm.org/D76833

show more ...

Clarify use of llvm_unreachable in the coding standard.

There has been some ongoing confusion regarding when to use `llvm_unreachable`
which this patch attempts to address. Specifically, the confusi

Clarify use of llvm_unreachable in the coding standard.

There has been some ongoing confusion regarding when to use `llvm_unreachable`
which this patch attempts to address. Specifically, the confusion has been
around whether `llvm_unreachable` is intended to mark only unreachable code
paths that the compiler cannot determine itself or to mark a code path which is
unconditionally a bug to reach. Based on email and IRC discussions, it sounds
like "unconditional bug to reach" is the consensus.

show more ...

Add coding standard recommending use of qualifiers in cpp files

There is prior art for this in the code base itself, and a recent
example of this here: c45f8d49897f

This came up in discussion on th

Add coding standard recommending use of qualifiers in cpp files

There is prior art for this in the code base itself, and a recent
example of this here: c45f8d49897f

This came up in discussion on this review where @maskray was going the
opposite direction:
https://reviews.llvm.org/D68772

Given that there is disagreement, we should make a choice and document
it.

Thanks to John McCall for the precise wording.

Reviewed By: MaskRay, rjmccall

Differential Revision: https://reviews.llvm.org/D74515

show more ...

[CodingStandards] Add link to "Picking the Right Data Structure"

See https://reviews.llvm.org/D74340

[CodingStandards] Clarify C++ Standard Library usage

The existing wording leaves it unclear if C++ standard library data
structures should be preferred over custom LLVM ones, e.g., SmallVector,
even

[CodingStandards] Clarify C++ Standard Library usage

The existing wording leaves it unclear if C++ standard library data
structures should be preferred over custom LLVM ones, e.g., SmallVector,
even though common practice seems clear on the issue. This change makes
the wording more explicit and aligns it better with the code base.

Some motivating statistics:

```
ag SmallVector llvm/lib/ | wc
8846 40306 901421
ag 'std::vector' llvm/lib/ | wc
2123 8990 214482

ag SmallVector clang/lib/ | wc
3023 13824 281691
ag 'std::vector' clang/lib/ | wc
719 2914 72817
```

Differential Revision: https://reviews.llvm.org/D74340

show more ...

[llvm] NFC: fix trivial typos in documents

Reviewers: hans, Jim

Reviewed By: Jim

Subscribers: jvesely, nhaehnle, mgorny, arphaman, bmahjour, kerbowa, llvm-commits

Tags: #llvm

Differential Revisi

[llvm] NFC: fix trivial typos in documents

Reviewers: hans, Jim

Reviewed By: Jim

Subscribers: jvesely, nhaehnle, mgorny, arphaman, bmahjour, kerbowa, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D73017

show more ...

Make coding standards document more inclusive

Summary: Patch by Doug Gregor, Tres Popp, and Dmitri Gribenko.

Reviewers: chandlerc

Subscribers: hfinkel, bmcreusillet, arsenm, doug.gregor, mgrang, a

Make coding standards document more inclusive

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

show more ...

Remove a no longer accurate sentence from the coding standards.

(And test my commit access. We're working on larger changes here.)

Move to C++14

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 agreeme

Move to C++14

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

show more ...

Update the coding standards with the new file header.

llvm-svn: 351652

Document how to comment an actual parameter.

Differential Revision: https://reviews.llvm.org/D54446

llvm-svn: 346861

[IR] Replace `isa<TerminatorInst>` with `isTerminator()`.

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

[IR] Replace `isa<TerminatorInst>` with `isTerminator()`.

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

show more ...