Summary: If a module has debug info, the size of debug symbol will be displayed after the Symbols Loaded Message for each module in the VScode modules view.{F12335461}
Reviewers: wallace, clayborg
Reviewed By: wallace, clayborg
Subscribers: cfe-commits, aprantl, lldb-commits
Tags: #lldb, #clang
Differential Revision: https://reviews.llvm.org/D83731
Summary:
https://bugs.llvm.org/show_bug.cgi?id=46043
Git's config is generally of the format 'key=val', but a setting
'key=true' can be written as just 'key'. The git-clang-format script
expects a value and crashes in this case; this change handles implicit
'true' values in the script.
Reviewers: MyDeveloperDay, krasimir, sammccall
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80486
Summary:
Add --relative to the suggested git-diff one liner. If the user does not
pass this argument, then git will produce a diff with the path relative
to the repository root. If the user's working directory is not the
repository root, then clang-format will complain that the file is not
found. The --relative argument makes git produce a diff with the files
relative to the working directory.
Add note to doc string to warn users about the fact that filenames
embedded in the diff are used as-is with no attempts to "do what they
mean, not what they say"
Reviewers: djasper, alexfh, efriedma, klimek, thakis
Reviewed By: efriedma
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D79054
Summary: Testing for None should use the 'is' operator.
Reviewed By: MyDeveloperDay
Patch By: eagleoflqj
Tags: #clang-format
Differential Revision: https://reviews.llvm.org/D77974
Summary: Python 3.8 introduces a SyntaxWarning about string comparisons with 'is'. This commit updates the string comparison in clang-format.py that is done with 'is not' to '!='. This should not break compatibility with older python versions (tested 3.4.9, 2.7.17, 2.7.5, 3.8.0).
Reviewers: MyDeveloperDay, klimek, llvm-commits, cfe-commits
Reviewed By: MyDeveloperDay, klimek
Patch By: pseyfert
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D70664
Summary:
The current clang-format.py does not handle trailing newlines at the end of a file correctly.
Trailing empty lines get removed except one.
As far as I understand this is because clang-format gets fed from stdin and writes to stdout when called from clang-format.py.
In a "normal" file (with no trailing empty lines) the string that gets passed to clang-format does not contain a trailing '\n' after the '\n'.join from python.
The clang-format binary does not add a trailing newline to input from stdin, but (if there are multiple trailing '\n', all except one get removed).
When reading back this means that we see in python from a "normal" file a string with no trailing '\n'. From a file with (potentially multiple) empty line(s) at the end, we get a string with one trailing '\n' back in python. In the former case all is fine, in the latter case split('\n') makes one empty line at the end of the file out of the clang-format output. Desired would be instead that the **file** ends with a newline, but not with an empty line.
For the case that a user specifies a range to format (and wants to keep trailing empty lines) I did **not** try to fix this by simply removing all trailing newlines from the clang-format output. Instead, I add a '\n' to the unformatted file content (i.e. newline-terminate what is passed to clang-format) and then strip off the last newline from the output (which itself is now for sure the newline termination of the clang-format output).
(Should this get approved, I'll need someone to help me land this.)
Reviewers: klimek, MyDeveloperDay
Reviewed By: MyDeveloperDay
Patch By: pseyfert
Subscribers: cfe-commits, llvm-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D70864
update trailing newline treatment in clang-format.py
Summary:
Review comments in {D69854} recommended a simpler approach of creating the SMDiagnostics to remove much of the complexity. (thanks @thakis)
@vlad.tsyrklevich I've rebuilt on both Windows and Linux (running Linux with Address and Undefined sanitizers) over the clang code base
Reviewers: thakis, klimek, mitchell-stellar, vlad.tsyrklevich
Reviewed By: thakis
Subscribers: cfe-commits, thakis, vlad.tsyrklevich
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D69921
Summary:
By additional regex match, grouping of main include can be enabled in files that are not normally considered as a C/C++ source code.
For example, this might be useful in templated code, where template implementations are being held in *Impl.hpp files.
On the occassion, 'assume-filename' option description was reworded as it was misleading. It has nothing to do with `style=file` option and it does not influence sourced style filename.
Reviewers: rsmith, ioeric, krasimir, sylvestre.ledru, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, cfe-commits
Patch by: furdyna
Tags: #clang
Differential Revision: https://reviews.llvm.org/D67750
Summary:
D23319 introduced python3 compatibility to clang-format.py, this is however not reflected by the documentation in the comments at the beginning of the file, which show how to use the script with python2 in .vimrc. While the actual mapping a user might want to use may well differ from my suggestion, I think it's nice to show the python2 and python3 version, such that a user can pick from the suggestions instead of googeling the python3 replacement for `:pyf` which they might not be familiar with.
EDIT: picking reviewers according to https://llvm.org/docs/Phabricator.html#finding-potential-reviewers
Reviewers: klimek, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: ilya-biryukov, cfe-commits, llvm-commits, ychen
Patch By: pseyfert
Tags: #clang-tools-extra, #llvm, #clang
Differential Revision: https://reviews.llvm.org/D38446
Summary:
Adds asserts to catch empty filenames, which otherwise will cause a crash in SourceManager.
The clang-format tool now outputs an error if an empty filename is used.
Fixes bug: 34667
Reviewers: krasimir, djasper, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits
Patch by: @jr
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D56345
Summary:
This allows one to enable `clang-format-buffer` on file save and avoid
reformatting files that are outside of any project with .clang-format style.
Reviewers: djasper, klimek, sammccall, owenpan, mitchell-stellar, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits
Patch By: dottedmag
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D69752
This reverts commit ec66603ac7. It was
causing ubsan failures like the following on the ubsan bot:
llvm/lib/Support/SourceMgr.cpp:440:48: runtime error: pointer index expression with base 0x000000000000 overflowed to 0xfffffffffffffffa
Summary:
Review comments on {D68767} asked that this duplicated code in clang-format was moved to one central location that being SourceManager (where it had originally be copied from I assume)
Moved function into static function ContentCache::getInvalidBOM(...) - (closest class to where it was defined before)
Updated clang-format to call this static function
Added unit tests for said new function in BasicTests
Sorry not my normal code area so may have the wrong reviewers. (but your names were on the recent history)
Reviewers: bruno, arphaman, klimek, owenpan, mitchell-stellar, dexonsmith
Reviewed By: owenpan
Subscribers: cfe-commits
Tags: #clang, #clang-format, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D68914
Summary:
Address review comments from {D68554} by trying to drop the dependency again on Frontend whilst keeping the same format diagnostic messages
Not completely happy with having to do a split in order to get the StringRef for the Line the error occurred on, but could see a way to use SourceManager and SourceLocation to give me a single line?
But this removes the dependency on frontend which should keep the binary size down.
Reviewers: thakis, klimek, mitchell-stellar
Reviewed By: klimek
Subscribers: mgorny, cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D68969
Summary:
Related somewhat to {D29039}
On seeing a quote on twitter by @invalidop
> If it's not formatted with clang-format it's a build error.
This made me want to change the way I use clang-format into a tool that could optionally show me where my source code violates clang-format syle.
When I'm making a change to clang-format itself, one thing I like to do to test the change is to ensure I didn't cause a huge wave of changes, what I want to do is simply run this on a known formatted directory and see if any new differences arrive in a manner I'm used to.
This started me thinking that we should allow build systems to run clang-format on a whole tree and emit compiler style warnings about files that fail clang-format in a form that would make them as a warning in most build systems and because those build systems range in their construction I don't think its unreasonable to NOT expect them to have to do the directory searching or parsing the output replacements themselves, but simply transform that into an error code when there are changes required.
I am starting this by suggesing adding a -n or -dry-run command line argument which would emit a warning/error of the form
Support for various common compiler command line argumuments like '-Werror' and '-ferror-limit' could make this very flexible to be integrated into build systems and CI systems.
```
> $ /usr/bin/clang-format --dry-run ClangFormat.cpp -ferror-limit=3 -fcolor-diagnostics
> ClangFormat.cpp:54:29: warning: code should be clang-formatted [-Wclang-format-violations]
> static cl::list<std::string>
> ^
> ClangFormat.cpp:55:20: warning: code should be clang-formatted [-Wclang-format-violations]
> LineRanges("lines", cl::desc("<start line>:<end line> - format a range of\n"
> ^
> ClangFormat.cpp:55:77: warning: code should be clang-formatted [-Wclang-format-violations]
> LineRanges("lines", cl::desc("<start line>:<end line> - format a range of\n"
> ^
```
Reviewers: mitchell-stellar, klimek, owenpan
Reviewed By: klimek
Subscribers: mgorny, cfe-commits
Tags: #clang-format, #clang-tools-extra, #clang
Differential Revision: https://reviews.llvm.org/D68554
llvm-svn: 374663
Summary:
Before making a proposed change, ensure ClangFormat.cpp is fully clang-formatted,
no functional change just clang-formatting using the in tree .clang-format.
Reviewers: mitchell-stellar
Reviewed By: mitchell-stellar
Subscribers: Eugene.Zelenko, cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D68551
llvm-svn: 373921
Summary: https://bugs.llvm.org/show_bug.cgi?id=36858 identifies .hh as a missing C++ header extension file while making this change I realized there was no support for .cs files which were added recently
Reviewers: pseyfert, klimek, owenpan
Reviewed By: klimek
Subscribers: cfe-commits
Tags: #clang-tools-extra, #clang
Differential Revision: https://reviews.llvm.org/D67949
llvm-svn: 372760
Update the callers of FileManager::getFile and FileManager::getDirectory to handle the new llvm::ErrorOr-returning methods.
Signed-off-by: Harlan Haskins <harlan@apple.com>
llvm-svn: 367616
The description in clang-format-diff.py is more useful than the one
in `clang-format-diff -h`, so use the same description in both places.
Differential Revision: https://reviews.llvm.org/D64998
llvm-svn: 366828
Summary:
This allows downstream customizations to the default style to work without
needing to also modify the editor integrations.
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49719
llvm-svn: 360996
Summary:
This revision adds basic support for formatting C# files with clang-format, I know the barrier to entry is high here so I'm sending this revision in to test the water as to whether this might be something we'd consider landing.
Tracking in Bugzilla as:
https://bugs.llvm.org/show_bug.cgi?id=40850
Justification:
C# code just looks ugly in comparison to the C++ code in our source tree which is clang-formatted.
I've struggled with Visual Studio reformatting to get a clean and consistent style, I want to format our C# code on saving like I do now for C++ and i want it to have the same style as defined in our .clang-format file, so it consistent as it can be with C++. (Braces/Breaking/Spaces/Indent etc..)
Using clang format without this patch leaves the code in a bad state, sometimes when the BreakStringLiterals is set, it fails to compile.
Mostly the C# is similar to Java, except instead of JavaAnnotations I try to reuse the TT_AttributeSquare.
Almost the most valuable portion is to have a new Language in order to partition the configuration for C# within a common .clang-format file, with the auto detection on the .cs extension. But there are other C# specific styles that could be added later if this is accepted. in particular how `{ set;get }` is formatted.
Reviewers: djasper, klimek, krasimir, benhamilton, JonasToth
Reviewed By: klimek
Subscribers: llvm-commits, mgorny, jdoerfert, cfe-commits
Tags: #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D58404
llvm-svn: 356662
The python documentation says "it’s highly recommended that you use raw strings for all but the simplest expressions." (https://docs.python.org/3/library/re.html)
So do that with the attached patch generated by
sed -i -e "s/re.search('/re.search(r'/g" $(git grep -l 're.search(')
The warning can be seen in e.g. python3.7:
$ python3.7 -Wd
>>> import re; re.search('\s', '')
<stdin>:1: DeprecationWarning: invalid escape sequence \s
Commited on behalf of Marco Falke.
Differential Revision: https://reviews.llvm.org/D57528
llvm-svn: 353707
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
StringIO is obsoleted in Python3, replaced by io.BytesIO or io.StringIO depending on the use.
Differential Revision: https://reviews.llvm.org/D55196
llvm-svn: 350318
Using from __future__ import print_function it is possible to have a compatible behavior of `print(...)` across Python version.
Differential Revision: https://reviews.llvm.org/D55213
llvm-svn: 349454
This patch moves the virtual file system form clang to llvm so it can be
used by more projects.
Concretely the patch:
- Moves VirtualFileSystem.{h|cpp} from clang/Basic to llvm/Support.
- Moves the corresponding unit test from clang to llvm.
- Moves the vfs namespace from clang::vfs to llvm::vfs.
- Formats the lines affected by this change, mostly this is the result of
the added llvm namespace.
RFC on the mailing list:
http://lists.llvm.org/pipermail/llvm-dev/2018-October/126657.html
Differential revision: https://reviews.llvm.org/D52783
llvm-svn: 344140
Summary: It is not necessary, but would be nice if the script run on python3 as well (as opposed to only python2, which is going to be deprecated https://pythonclock.org/)
Contributed by MarcoFalke!
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: lebedev.ri, sammccall, cfe-commits
Differential Revision: https://reviews.llvm.org/D48098
llvm-svn: 338839
Summary:
Tools that reformat code often call `getStyle` to decide the format style
to use on a certain source file. In practice, "file" style is widely used. As a
result, many tools hardcode "file" when calling `getStyle`, which makes it hard
to control the default style in tools across a codebase when needed. This change
introduces a `DefaultFormatStyle` constant (default to "file" in upstream), which
can be modified downstream if wanted, so that all users/tools built from the same
source tree can have a consistent default format style.
This also adds an DefaultFallbackStyle that is recommended to be used by tools and can be modified downstream.
Reviewers: sammccall, djasper
Reviewed By: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48492
llvm-svn: 335492
This is similar to the LLVM change https://reviews.llvm.org/D46290.
We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.
Patch produced by
for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done
Differential Revision: https://reviews.llvm.org/D46320
llvm-svn: 331834
Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:
archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru
Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)
Differential revision: https://reviews.llvm.org/D44188
llvm-svn: 329399
Summary:
`clang-format -dump-config path/to/file.h` never passed
anything for the Code parameter to clang::format::getStyle().
This meant the logic to guess Objective-C from the contents
of a .h file never worked, because LibFormat didn't have the
code to work with.
With this fix, we now correctly read in the contents of the
file if possible with -dump-config.
I had to update the lit config for test/Format/ because
the default config ignores .h files.
Test Plan: make -j12 check-clang
Reviewers: jolesiak, krasimir
Reviewed By: jolesiak, krasimir
Subscribers: Wizard, klimek, cfe-commits, djasper
Differential Revision: https://reviews.llvm.org/D42395
llvm-svn: 323668
Clang supports compiling CUDA source files for some time,
format them by default as well.
Differential Revision: https://reviews.llvm.org/D42589
llvm-svn: 323615
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
llvm-svn: 319840
Walter Erquinigo