With 118f966b46, Clang matches GCC's behaviour and allows enabling
-Wdeclaration-after-statement with C99 and later.
However, the check for mixing declarations and code is not a constant time
algorithm, and therefore should be guarded with Diags.isIgnored().
Furthermore, improve test coverage with: non-pedantic C89 with the
warning; C11 with the warning; and when using -Wall.
Finally, mention the changed behaviour in ReleaseNotes.rst.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D117232
This patch adds support for the MSVC /HOTPATCH flag: https://docs.microsoft.com/sv-se/cpp/build/reference/hotpatch-create-hotpatchable-image?view=msvc-170&viewFallbackFrom=vs-2019
The flag is translated to a new -fms-hotpatch flag, which in turn adds a 'patchable-function' attribute for each function in the TU. This is then picked up by the PatchableFunction pass which would generate a TargetOpcode::PATCHABLE_OP of minsize = 2 (which means the target instruction must resolve to at least two bytes). TargetOpcode::PATCHABLE_OP is only implemented for x86/x64. When targetting ARM/ARM64, /HOTPATCH isn't required (instructions are always 2/4 bytes and suitable for hotpatching).
Additionally, when using /Z7, we generate a 'hot patchable' flag in the CodeView debug stream, in the S_COMPILE3 record. This flag is then picked up by LLD (or link.exe) and is used in conjunction with the linker /FUNCTIONPADMIN flag to generate extra space before each function, to accommodate for live patching long jumps. Please see: d703b92296/lld/COFF/Writer.cpp (L1298)
The outcome is that we can finally use Live++ or Recode along with clang-cl.
NOTE: It seems that MSVC cl.exe always enables /HOTPATCH on x64 by default, although if we did the same I thought we might generate sub-optimal code (if this flag was active by default). Additionally, MSVC always generates a .debug$S section and a S_COMPILE3 record, which Clang doesn't do without /Z7. Therefore, the following MSVC command-line "cl /c file.cpp" would have to be written with Clang such as "clang-cl /c file.cpp /HOTPATCH /Z7" in order to obtain the same result.
Depends on D43002, D80833 and D81301 for the full feature.
Differential Revision: https://reviews.llvm.org/D116511
C17 deprecated ATOMIC_VAR_INIT with the resolution of DR 485. C++
followed suit when adopting P0883R2 for C++20, but additionally chose
to deprecate ATOMIC_FLAG_INIT at the same time despite the macro still
being required in C. This patch marks both macros as deprecated when
appropriate to do so.
This style is similar to AlwaysBreak, but places closing brackets on new lines.
For example, if you have a multiline parameter list, clang-format currently only supports breaking per-parameter, but places the closing bracket on the line of the last parameter.
Function(
param1,
param2,
param3);
A style supported by other code styling tools (e.g. rustfmt) is to allow the closing brackets to be placed on their own line, aiding the user in being able to quickly infer the bounds of the block of code.
Function(
param1,
param2,
param3
);
For prior work on a similar feature, see: https://reviews.llvm.org/D33029.
Note: This currently only supports block indentation for closing parentheses.
Differential Revision: https://reviews.llvm.org/D109557
This completes the implementation of
WG14 N2412 (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf),
which standardizes C on a twos complement representation for integer
types. The only work that remained there was to define the correct
macros in the standard headers, which this patch does.
I noticed that the following case would compile in Clang but not GCC:
void *x(void) {
void *p = &&foo;
asm goto ("# %0\n\t# %l1":"+r"(p):::foo);
foo:;
return p;
}
Changing the output template above from %l2 would compile in GCC but not
Clang.
This demonstrates that when using tied outputs (say via the "+r" output
constraint), the hidden inputs occur or are numbered BEFORE the labels,
at least with GCC.
In fact, GCC does denote this in its documentation:
https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Extended-Asm.html#Goto-Labels
> Output operand with constraint modifier ‘+’ is counted as two operands
> because it is considered as one output and one input operand.
For the sake of compatibility, I think it's worthwhile to just make this
change.
It's better to use symbolic names for compatibility (especially now
between released version of Clang that support asm goto with outputs).
ie. %l1 from the above would be %l[foo]. The GCC docs also make this
recommendation.
Also, I cleaned up some cruft in GCCAsmStmt::getNamedOperand. AFAICT,
NumPlusOperands was no longer used, though I couldn't find which commit
didn't clean that up correctly.
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98096
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103640
Link: https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Extended-Asm.html#Goto-Labels
Reviewed By: void
Differential Revision: https://reviews.llvm.org/D115471
Previously this was documented as having the behavior of the
"target's native float-to-int conversion". After D115804, clang
uses saturating FP cast intrinsics which have the same behavior
on all targets.
Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D116856
This change adds an option AfterOverloadedOperator in SpaceBeforeParensOptions to add a space between overloaded operator and opening parentheses in clang-format.
Reviewed By: MyDeveloperDay, curdeius, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D116283
This commit resolves GitHub issue #45895 (Bugzilla #46550), to
add or remove empty line between definition blocks including
namespaces, classes, structs, enums and functions.
Reviewed By: MyDeveloperDay, curdeius, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D116314
This diff extends the -style=file option to allow a config file to be specified explicitly. This is useful (for instance) when adding IDE commands to reformat code to a personal style.
Usage: `clang-format -style=file:<path/to/config/file> ...`
Reviewed By: HazardyKnusperkeks, curdeius, MyDeveloperDay, zwliew
Differential Revision: https://reviews.llvm.org/D72326
Extends response file expansion to recognize `<CFGDIR>` and expand to the
current file's directory. This makes it much easier to author clang config
files rooted in portable, potentially not-installed SDK directories.
A typical use case may be something like the following:
```
# sample_sdk.cfg
--target=sample
-isystem <CFGDIR>/include
-L <CFGDIR>/lib
-T <CFGDIR>/ldscripts/link.ld
```
Reviewed By: sepavloff
Differential Revision: https://reviews.llvm.org/D115604
This reverts commit cc56c66f27.
Fixed a bad assertion, the target of a UsingShadowDecl must not have
*local* qualifiers, but it can be a typedef whose underlying type is qualified.
Currently there's no way to find the UsingDecl that a typeloc found its
underlying type through. Compare to DeclRefExpr::getFoundDecl().
Design decisions:
- a sugar type, as there are many contexts this type of use may appear in
- UsingType is a leaf like TypedefType, the underlying type has no TypeLoc
- not unified with UnresolvedUsingType: a single name is appealing,
but being sometimes-sugar is often fiddly.
- not unified with TypedefType: the UsingShadowDecl is not a TypedefNameDecl or
even a TypeDecl, and users think of these differently.
- does not cover other rarer aliases like objc @compatibility_alias,
in order to be have a concrete API that's easy to understand.
- implicitly desugared by the hasDeclaration ASTMatcher, to avoid
breaking existing patterns and following the precedent of ElaboratedType.
Scope:
- This does not cover types associated with template names introduced by
using declarations. A future patch should introduce a sugar TemplateName
variant for this. (CTAD deduced types fall under this)
- There are enough AST matchers to fix the in-tree clang-tidy tests and
probably any other matchers, though more may be useful later.
Caveats:
- This changes a fairly common pattern in the AST people may depend on matching.
Previously, typeLoc(loc(recordType())) matched whether a struct was
referred to by its original scope or introduced via using-decl.
Now, the using-decl case is not matched, and needs a separate matcher.
This is similar to the case of typedefs but nevertheless both adds
complexity and breaks existing code.
Differential Revision: https://reviews.llvm.org/D114251
In 2015-05, GCC added the configure option `--enable-default-pie`. When enabled,
* in the absence of -fno-pic/-fpie/-fpic (and their upper-case variants), -fPIE is the default.
* in the absence of -no-pie/-pie/-shared/-static/-static-pie, -pie is the default.
This has been adopted by all(?) major distros.
I think default PIE is the majority in the Linux world, but
--disable-default-pie users is not that uncommon because GCC upstream hasn't
switched the default yet (https://gcc.gnu.org/PR103398).
This patch add CLANG_DEFAULT_PIE_ON_LINUX which allows distros to use default PIE.
The option is justified as its adoption can be very high among Linux distros
to make Clang default match GCC, and is likely a future-new-default, at which
point we will remove CLANG_DEFAULT_PIE_ON_LINUX.
The lit feature `default-pie-on-linux` can be handy to exclude default PIE sensitive tests.
Reviewed By: foutrelis, sylvestre.ledru, thesamesam
Differential Revision: https://reviews.llvm.org/D113372
Some users have a need to control attribute extension diagnostics
independent of other extension diagnostics. Consider something like use
of [[nodiscard]] within C++11:
```
[[nodiscard]]
int f();
```
If compiled with -Wc++17-extensions enabled, this will produce warning:
use of the 'nodiscard' attribute is a C++17 extension. This diagnostic
is correct -- using [[nodiscard]] in C++11 mode is a C++17 extension.
And the behavior of __has_cpp_attribute(nodiscard) is also correct --
we support [[nodiscard]] in C++11 mode as a conforming extension. But
this makes use of -Werror or -pedantic-errors` builds more onerous.
This patch adds diagnostic groups for attribute extensions so that
users can selectively disable attribute extension diagnostics. I
believe this is preferable to requiring users to specify additional
flags because it means -Wc++17-extensions continues to be the way we
enable all C++17-related extension diagnostics. It would be quite easy
for someone to use that flag thinking they're protected from some
portability issues without realizing it skipped attribute extensions if
we went the other way.
This addresses PR33518.
WG14 adopted the _ExtInt feature from Clang for C23, but renamed the
type to be _BitInt. This patch does the vast majority of the work to
rename _ExtInt to _BitInt, which accounts for most of its size. The new
type is exposed in older C modes and all C++ modes as a conforming
extension. However, there are functional changes worth calling out:
* Deprecates _ExtInt with a fix-it to help users migrate to _BitInt.
* Updates the mangling for the type.
* Updates the documentation and adds a release note to warn users what
is going on.
* Adds new diagnostics for use of _BitInt to call out when it's used as
a Clang extension or as a pre-C23 compatibility concern.
* Adds new tests for the new diagnostic behaviors.
I want to call out the ABI break specifically. We do not believe that
this break will cause a significant imposition for early adopters of
the feature, and so this is being done as a full break. If it turns out
there are critical uses where recompilation is not an option for some
reason, we can consider using ABI tags to ease the transition.
Responding to a Discord call to help {D113977} and heavily inspired by the unlanded {D34225} add some support to help coroutinues from not being formatted from
```for co_await(auto elt : seq)```
to
```
for
co_await(auto elt : seq)
```
Because of the dominance of clang-format in the C++ community, I don't think we should make it the blocker that prevents users from embracing the newer parts of the standard because we butcher the layout of some of the new constucts.
Reviewed By: HazardyKnusperkeks, Quuxplusone, ChuanqiXu
Differential Revision: https://reviews.llvm.org/D114859
https://bugs.llvm.org/show_bug.cgi?id=52517
clang-format is butchering modules, this could easily become a barrier to entry for modules given clang-formats wide spread use.
Prevent the following from adding spaces around the `:` (cf was considering the ':' as an InheritanceColon)
Reviewed By: HazardyKnusperkeks, owenpan, ChuanqiXu
Differential Revision: https://reviews.llvm.org/D114151
From GCC's manpage:
-fplugin-arg-name-key=value
Define an argument called key with a value of value for the
plugin called name.
Since we don't have a key-value pair similar to gcc's plugin_argument
struct, simply accept key=value here anyway and pass it along as-is to
plugins.
This translates to the already existing '-plugin-arg-pluginname arg'
that clang cc1 accepts.
There is an ambiguity here because in clang, both the plugin name
as well as the option name can contain dashes, so when e.g. passing
-fplugin-arg-foo-bar-foo
it is not clear whether the plugin is foo-bar and the option is foo,
or the plugin is foo and the option is bar-foo. GCC solves this by
interpreting all dashes as part of the option name. So dashes can't be
part of the plugin name in this case.
Differential Revision: https://reviews.llvm.org/D113250
Operations are emulated by software emulation and “float” instructions.
This patch is allowing the support of _Float16 type without the use of
-max512fp16 flag. The final goal being, perform _Float16 emulation for
all arithmetic expressions.
The coding style of some projects requires to have more control on space
before opening parentheses.
The goal is to add the support of clang-format to more projects.
For example adding a space only for function definitions or
declarations.
This revision adds SpaceBeforeParensOptions to configure each option
independently from one another.
Differentiel Revision: https://reviews.llvm.org/D110833
This provides better support for `LambdaCapture`s by making them first-
class and allowing them to be bindable. In addition, this implements several
`LambdaCapture`-related matchers. This does not update how lambdas are
traversed. As a result, something like trying to match `lambdaCapture()` by
itself will not work - it must be used as an inner matcher.
Reviewed By: aaron.ballman, sammccall
Differential Revision: https://reviews.llvm.org/D112491
This patch ensures that we always tune for a given CPU on AArch64
targets when the user specifies the "-mtune=xyz" flag. In the
AArch64Subtarget if the tune flag is unset we use the CPU value
instead.
I've updated the release notes here:
llvm/docs/ReleaseNotes.rst
and added tests here:
clang/test/Driver/aarch64-mtune.c
Differential Revision: https://reviews.llvm.org/D110258
Previously, we reported the same value as for C17, now we report 202000L, which
is the same value currently used by GCC.
Once C23 ships, this value will be bumped to the correct date.
The C and C++ standards require the argument to __has_cpp_attribute and
__has_c_attribute to be expanded ([cpp.cond]p5). It would make little sense
to expand the argument to those operators but not expand the argument to
__has_attribute and __has_declspec, so those were both also changed in this
patch.
Note that it might make sense for the other builtins to also expand their
argument, but it wasn't as clear to me whether the behavior would be correct
there, and so they were left for a future revision.
Developers these days seem to argue over east vs west const like they used to argue over tabs vs whitespace or the various bracing style. These previous arguments were mainly eliminated with tools like `clang-format` that allowed those rules to become part of your style guide. Anyone who has been using clang-format in a large team over the last couple of years knows that we don't have those religious arguments any more, and code reviews are more productive.
https://www.youtube.com/watch?v=fv--IKZFVO8https://mariusbancila.ro/blog/2018/11/23/join-the-east-const-revolution/https://www.youtube.com/watch?v=z6s6bacI424
The purpose of this revision is to try to do the same for the East/West const discussion. Move the debate into the style guide and leave it there!
In addition to the new `ConstStyle: Right` or `ConstStyle: Left` there is an additional command-line argument `--const-style=left/right` which would allow an individual developer to switch the source back and forth to their own style for editing, and back to the committed style before commit. (you could imagine an IDE might offer such a switch)
The revision works by implementing a separate pass of the Annotated lines much like the SortIncludes and then create replacements for constant type declarations.
Differential Revision: https://reviews.llvm.org/D69764
SelectionDAG will promote illegal types up to a power of 2 before
splitting down to a legal type. This will create an IntegerType
with a bit width that must be <= MAX_INT_BITS. This places an
effective upper limit on any type of 2^23 so that we don't try
create a 2^24 type.
I considered putting a fatal error somewhere in the path from
TargetLowering::getTypeConversion down to IntegerType::get, but
limiting the type in IR seemed better.
This breaks backwards compatibility with IR that is using a really
large type. I suspect such IR is going to be very rare due to the
the compile time costs such a type likely incurs.
Prevents the ICE in PR51829.
Reviewed By: efriedma, aaron.ballman
Differential Revision: https://reviews.llvm.org/D109721
Add documentation of clang-nvlink-wrapper tool in clang.
Add it to the release notes of clang. Fix a small MSVC
warning.
Differential Revision: https://reviews.llvm.org/D109225
This change would treat the token `or` in system headers as an
identifier, and elsewhere as an operator. As reported in
llvm.org/pr42427, many users classify their third party library headers
as "system" headers to suppress warnings. There's no clean way to
separate Windows SDK headers from user headers.
Clang is still able to parse old Windows SDK headers if C++ operator
names are disabled. Traditionally this was controlled by
`-fno-operator-names`, but is now also enabled with `/permissive` since
D103773. This change will prevent `clang-cl` from parsing <query.h> from
the Windows SDK out of the box, but there are multiple ways to work
around that:
- Pass `/clang:-fno-operator-names`
- Pass `/permissive`
- Pass `-DQUERY_H_RESTRICTION_PERMISSIVE`
In all of these modes, the operator names will consistently be available
or not available, instead of depending on whether the code is in a
system header.
I added a release note for this, since it may break straightforward
users of the Windows SDK.
Fixes PR42427
Differential Revision: https://reviews.llvm.org/D108720
Add support for the GNU C style __attribute__((error(""))) and
__attribute__((warning(""))). These attributes are meant to be put on
declarations of functions whom should not be called.
They are frequently used to provide compile time diagnostics similar to
_Static_assert, but which may rely on non-ICE conditions (ie. relying on
compiler optimizations). This is also similar to diagnose_if function
attribute, but can diagnose after optimizations have been run.
While users may instead simply call undefined functions in such cases to
get a linkage failure from the linker, these provide a much more
ergonomic and actionable diagnostic to users and do so at compile time
rather than at link time. Users instead may be able use inline asm .err
directives.
These are used throughout the Linux kernel in its implementation of
BUILD_BUG and BUILD_BUG_ON macros. These macros generally cannot be
converted to use _Static_assert because many of the parameters are not
ICEs. The Linux kernel still needs to be modified to make use of these
when building with Clang; I have a patch that does so I will send once
this feature is landed.
To do so, we create a new IR level Function attribute, "dontcall" (both
error and warning boil down to one IR Fn Attr). Then, similar to calls
to inline asm, we attach a !srcloc Metadata node to call sites of such
attributed callees.
The backend diagnoses these during instruction selection, while we still
know that a call is a call (vs say a JMP that's a tail call) in an arch
agnostic manner.
The frontend then reconstructs the SourceLocation from that Metadata,
and determines whether to emit an error or warning based on the callee's
attribute.
Link: https://bugs.llvm.org/show_bug.cgi?id=16428
Link: https://github.com/ClangBuiltLinux/linux/issues/1173
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D106030
This should reduce the amount of noise issued by clang for the recent-ish CUDA
versions.
Clang still does not support all the features offered by NVCC, but is expected
to handle CUDA headers and produce binaries for all GPUs supported by NVCC.
Differential Revision: https://reviews.llvm.org/D108248
This implements P2362, which has not yet been approved by the
C++ committee, but because wide-multi character literals are
implementation defined, clang might not have to wait for WG21.
This change is also being applied in C mode as the behavior is
implementation-defined in C as well and there's no benefit to
having different rules between the languages.
The other part of P2362, making non-representable character
literals ill-formed, is already implemented by clang
Previously, with AllowShortEnumsOnASingleLine disabled, enums that would have otherwise fit on a single line would always put the opening brace on its own line.
This patch ensures that these enums will only put the brace on its own line if the existing attachment rules indicate that it should.
Reviewed By: HazardyKnusperkeks, curdeius
Differential Revision: https://reviews.llvm.org/D99840
Summary:
Test and produce warning for subtracting a pointer from null or subtracting
null from a pointer.
This reland adds the functionality that the warning is no longer reusing an
existing warning, it has different wording for C vs C++ to refect the fact
that nullptr-nullptr has defined behaviour in C++, it is suppressed
when the warning is triggered by a system header and adds
-Wnull-pointer-subtraction to allow the warning to be controlled. -Wextra
implies -Wnull-pointer-subtraction.
Author: Jamie Schmeiser <schmeise@ca.ibm.com>
Reviewed By: efriedma (Eli Friedman), nickdesaulniers (Nick Desaulniers)
Differential Revision: https://reviews.llvm.org/D98798
I find as I develop I'm moving between many different languages C++,C#,JavaScript all the time. As I move between the file types I like to keep `clang-format` as my formatting tool of choice. (hence why I initially added C# support in {D58404}) I know those other languages have their own tools but I have to learn them all, and I have to work out how to configure them, and they may or may not have integration into my IDE or my source code integration.
I am increasingly finding that I'm editing additional JSON files as part of my daily work and my editor and git commit hooks are just not setup to go and run [[ https://stedolan.github.io/jq/ | jq ]], So I tend to go to [[ https://jsonformatter.curiousconcept.com/ | JSON Formatter ]] and copy and paste back and forth. To get nicely formatted JSON. This is a painful process and I'd like a new one that causes me much less friction.
This has come up from time to time:
{D10543}
https://stackoverflow.com/questions/35856565/clang-format-a-json-filehttps://bugs.llvm.org/show_bug.cgi?id=18699
I would like to stop having to do that and have formatting JSON as a first class clang-format support `Language` (even if it has minimal style settings at present).
This revision adds support for formatting JSON using the inbuilt JSON serialization library of LLVM, With limited control at present only over the indentation level
This adds an additional Language into the .clang-format file to separate the settings from your other supported languages.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D93528
Currently the lambda body indents relative to where the lambda signature is located. This instead lets the user
choose to align the lambda body relative to the parent scope that contains the lambda declaration. Thus:
someFunction([] {
lambdaBody();
});
will always have the same indentation of the body even when the lambda signature goes on a new line:
someFunction(
[] {
lambdaBody();
});
whereas before lambdaBody would be indented 6 spaces.
Differential Revision: https://reviews.llvm.org/D102706
This allows to set a different indent width for preprocessor statements.
Example:
#ifdef __linux_
# define FOO
#endif
int main(void)
{
return 0;
}
Differential Revision: https://reviews.llvm.org/D103286
This re-applies the old patch D27651, which was never landed, into the
latest "main" branch, without understanding the code. I just applied
the changes "mechanically" and made it compiling again.
This makes the right pointer alignment working as expected.
Fixes https://llvm.org/PR27353
For instance
const char* const* v1;
float const* v2;
SomeVeryLongType const& v3;
was formatted as
const char *const * v1;
float const * v2;
SomeVeryLongType const &v3;
This patch keep the *s or &s aligned to the right, next to their variable.
The above example is now formatted as
const char *const *v1;
float const *v2;
SomeVeryLongType const &v3;
It is a pity that this still does not work with clang-format in 2021,
even though there was a fix available in 2016. IMHO right pointer alignment
is the default case in C, because syntactically the pointer belongs to the
variable.
See
int* a, b, c; // wrong, just the 1st variable is a pointer
vs.
int *a, *b, *c; // right
Prominent example is the Linux kernel coding style.
Some styles argue the left pointer alignment is better and declaration
lists as shown above should be avoided. That's ok, as different projects
can use different styles, but this important style should work too.
I hope that somebody that has a better understanding about the code,
can take over this patch and land it into main.
For now I must maintain this fork to make it working for our projects.
Cheers,
Gerhard.
Differential Revision: https://reviews.llvm.org/D103245
This is a re-application of dc67299 which was reverted in f63adf5b because
it broke the build. The issue should now be fixed.
Attribution note: The original author of this patch is Erik Pilkington.
I'm only trying to land it after rebasing.
Differential Revision: https://reviews.llvm.org/D91630
This inheritance list style has been widely adopted by Symantec,
a division of Broadcom Inc. It breaks after the commas that
separate the base-specifiers:
class Derived : public Base1,
private Base2
{
};
Differential Revision: https://reviews.llvm.org/D103204
This patch adds support for GCC's -fstack-usage flag. With this flag, a stack
usage file (i.e., .su file) is generated for each input source file. The format
of the stack usage file is also similar to what is used by GCC. For each
function defined in the source file, a line with the following information is
produced in the .su file.
<source_file>:<line_number>:<function_name> <size_in_byte> <static/dynamic>
"Static" means that the function's frame size is static and the size info is an
accurate reflection of the frame size. While "dynamic" means the function's
frame size can only be determined at run-time because the function manipulates
the stack dynamically (e.g., due to variable size objects). The size info only
reflects the size of the fixed size frame objects in this case and therefore is
not a reliable measure of the total frame size.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D100509
This fixes PR46992.
Git stores symlinks as text files and we should not format them even if
they have one of the requested extensions.
(Move the call to `cd_to_toplevel()` up a few lines so we can also print
the skipped symlinks during verbose output.)
Differential Revision: https://reviews.llvm.org/D101878
Warn when a declaration uses an identifier that doesn't obey the reserved
identifier rule from C and/or C++.
Differential Revision: https://reviews.llvm.org/D93095
A need for such an option came up in a few libc++ reviews. That's because libc++ has both code in C++03 and newer standards.
Currently, it uses `Standard: C++03` setting for clang-format, but this breaks e.g. u8"string" literals.
Also, angle brackets are the only place where C++03-specific formatting needs to be applied.
Reviewed By: MyDeveloperDay, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D101344
Fixes https://llvm.org/PR41870.
Checks for newlines in option Style.EmptyLineBeforeAccessModifier are now based on the formatted new lines and not on the new lines in the file.
Reviewed By: HazardyKnusperkeks, curdeius
Differential Revision: https://reviews.llvm.org/D99503
This is a Clang-only change and depends on the existing "musttail"
support already implemented in LLVM.
The [[clang::musttail]] attribute goes on a return statement, not
a function definition. There are several constraints that the user
must follow when using [[clang::musttail]], and these constraints
are verified by Sema.
Tail calls are supported on regular function calls, calls through a
function pointer, member function calls, and even pointer to member.
Future work would be to throw a warning if a users tries to pass
a pointer or reference to a local variable through a musttail call.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D99517
The current logic for access modifiers in classes ignores the option 'MaxEmptyLinesToKeep=1'. It is therefore impossible to have a coding style that requests one empty line after an access modifier. The patch allows the user to configure how many empty lines clang-format should add after an access modifier. This will remove lines if there are to many and will add them if there are missing.
Reviewed By: MyDeveloperDay, curdeius
Differential Revision: https://reviews.llvm.org/D98237
In GCC, if `-B $prefix` is specified, `$prefix` is used to find executable files and startup files.
`$prefix/include` is added as an include search directory.
Clang overloads -B with GCC installation detection semantics which make the
behavior less predictable (due to the "largest GCC version wins" rule) and
interact poorly with --gcc-toolchain (--gcc-toolchain can be overridden by -B).
* `clang++ foo.cpp` detects GCC installation under `/usr`.
* `clang++ --gcc-toolchain=Inputs foo.cpp` detects GCC installation under `Inputs`.
* `clang++ -BA --gcc-toolchain=B foo.cpp` detects GCC installation under A and B and the larger version wins. With this patch, only B is used for detection.
* `clang++ -BA foo.cpp` detects GCC installation under `A` and `/usr`, and the larger GCC version wins. With this patch `A` is not used for detection.
This patch changes -B to drop the GCC detection semantics. Its executable
searching semantics are preserved. --gcc-toolchain is the recommended option to
specify the GCC installation detection directory.
(
Note: Clang detects GCC installation in various target dependent directories.
`$sysroot/usr` (sysroot defaults to "") is a common directory used by most targets.
Such a directory is expected to contain something like `lib{,32,64}/gcc{,-cross}/$triple`.
Clang will then construct library/include paths from the directory.
)
Differential Revision: https://reviews.llvm.org/D97993
This commit removes the old way of handling Whitesmiths mode in favor of just setting the
levels during parsing and letting the formatter handle it from there. It requires a bit of
special-casing during the parsing, but ends up a bit cleaner than before. It also removes
some of switch/case unit tests that don't really make much sense when dealing with
Whitesmiths.
Differential Revision: https://reviews.llvm.org/D94500
clang-format documentation states that having enabled
FixNamespaceComments one may expect below code:
c++
namespace a {
foo();
}
to be turned into:
c++
namespace a {
foo();
} // namespace a
In reality, no "// namespace a" was added. The problem was too high
value of kShortNamespaceMaxLines, which is used while deciding whether
a namespace is long enough to be formatted.
As with 9163fe2, clang-format idempotence is preserved.
Differential Revision: https://reviews.llvm.org/D87587
LIBCLANG_INCLUDE_CLANG_TOOLS_EXTRA causes clang-tools-extra tools
to be included in libclang, which caused a dependency cycle. The option
has been off by default for two releases now, and (based on a web search
and mailing list feedback) nobody seems to turn it on. Remove it, like
planned on https://reviews.llvm.org/D79599
Differential Revision: https://reviews.llvm.org/D97693
Adds support for coding styles that make a separate indentation level for access modifiers, such as Code::Blocks or QtCreator.
The new option, `IndentAccessModifiers`, if enabled, forces the content inside classes, structs and unions (“records”) to be indented twice while removing a level for access modifiers. The value of `AccessModifierOffset` is disregarded in this case, aiming towards an ease of use.
======
The PR (https://bugs.llvm.org/show_bug.cgi?id=19056) had an implementation attempt by @MyDeveloperDay already (https://reviews.llvm.org/D60225) but I've decided to start from scratch. They differ in functionality, chosen approaches, and even the option name. The code tries to re-use the existing functionality to achieve this behavior, limiting possibility of breaking something else.
Reviewed By: MyDeveloperDay, curdeius, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D94661
https://bugs.llvm.org/show_bug.cgi?id=40858
CheckShadow is now called for each binding in the structured binding to make sure it does not shadow any other variable in scope. This does use a custom implementation of getShadowedDeclaration though because a BindingDecl is not a VarDecl
Added a few unit tests for this. In theory though all the other shadow unit tests should be duplicated for the structured binding variables too but whether it is probably not worth it as they use common code. The MyTuple and std interface code has been copied from live-bindings-test.cpp
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D96147
This allows the define BasedOnStyle: InheritParentConfig and then
clang-format looks into the parent directories for their
.clang-format and takes that as a basis.
Differential Revision: https://reviews.llvm.org/D93844
Adds an option to [clang-format] which sorts headers in an alphabetical manner using case only for tie-breakers. The options is off by default in favor of the current ASCIIbetical sorting style.
Reviewed By: MyDeveloperDay, curdeius, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D95017
Marco Elver