Handles clang::DiagnosticsEngine and clang::DiagnosticIDs.
For DiagnosticIDs, this mostly migrates from `new DiagnosticIDs` to
convenience method `DiagnosticIDs::create()`.
Part of cleanup https://github.com/llvm/llvm-project/issues/151026
This switches to `makeIntrusiveRefCnt<FileSystem>` where creating a new
object, and to passing/returning by `IntrusiveRefCntPtr<FileSystem>`
instead of `FileSystem*` or `FileSystem&`, when dealing with existing
objects.
Part of cleanup #151026.
This reverts commit 897ccddcc30cacdfe04ddd622986b50ec963eabc. It
introduced a bug when formatting multiple files in one go. When a
shorter file is passed after a longer one, a stale length from the
previous file seems to be used, triggering an "invalid length (...) is
outside the file" error.
This reverts commit e2a885537f11f8d9ced1c80c2c90069ab5adeb1d. Build failures were fixed right away and reverting the original commit without the fixes breaks the build again.
The `DiagnosticOptions` class is currently intrusively
reference-counted, which makes reasoning about its lifetime very
difficult in some cases. For example, `CompilerInvocation` owns the
`DiagnosticOptions` instance (wrapped in `llvm::IntrusiveRefCntPtr`) and
only exposes an accessor returning `DiagnosticOptions &`. One would
think this gives `CompilerInvocation` exclusive ownership of the object,
but that's not the case:
```c++
void shareOwnership(CompilerInvocation &CI) {
llvm::IntrusiveRefCntPtr<DiagnosticOptions> CoOwner = &CI.getDiagnosticOptions();
// ...
}
```
This is a perfectly valid pattern that is being actually used in the
codebase.
I would like to ensure the ownership of `DiagnosticOptions` by
`CompilerInvocation` is guaranteed to be exclusive. This can be
leveraged for a copy-on-write optimization later on. This PR changes
usages of `DiagnosticOptions` across `clang`, `clang-tools-extra` and
`lldb` to not be intrusively reference-counted.
With the --force (or -f) option, git-clang-format wipes out input files
excluded by a .clang-format-ignore file if they have unstaged changes.
This patch adds a hidden clang-format option --list-ignored that lists
such excluded files for git-clang-format to filter out.
Fixes#102459.
To support auto-conversion on z/OS text files need to be opened as text files. These changes will fix a number of LIT failures due to text files not being converted to the internal code page.
update a number of tools so they open the text files as text files
add support in the cat.py to open a text file as a text file (Windows will continue to treat all files as binary so new lines are handled correctly)
add env var definitions to enable auto-conversion in the lit config file.
At the moment clang-format will return exit code 0 on incomplete
results. In scripts it would sometimes be useful if clang-format would
instead fail in those cases, signalling that there was something wrong
with the code being formatted.
---------
Co-authored-by: Björn Schäpers <github@hazardy.de>
Co-authored-by: Owen Pan <owenpiano@gmail.com>
This reverts commit b92d6dd704d789240685a336ad8b25a9f381b4cc. See
github.com/llvm/llvm-project/commit/b92d6dd704d7#commitcomment-139992444
We should use a tool like Visual Studio to clean up the headers.
Commit d813af73f70f addressed a regression introduced by commit
3791b3fca6ea
but caused `clang-format -dump-config` to "hang".
This patch reverts changes to ClangFormat.cpp by both commits and
reworks the cleanup.
Fixes#80621.
The code cleanup in #74794 accidentally broke detection of languages by
reading file content from stdin, e.g. via `clang-format -dump-config - <
/path/to/filename`.
This PR adds unit and integration tests to reproduce the issue and adds
a fix.
Fixes: #79023
(42ec976184ac was reverted by 26993f61673e due to a use-after-scope bug.)
Reuse the patterns governing the previous input file being formatted if
the current input file is from the same directory.
This reverts commit 42ec976184acd40436acd7104ad715c60ca3e7ed.
Reason: Broke the sanitizer buildbots. See more information on the
github comment thread at
42ec976184
Running `dump_format_help.py` in `clang/docs/tools`:
```
warning: line too long:
relative to the current working directory when reading stdin.
warning: line too long:
--files=<filename> - A file containing a list of files to process, one per line.
warning: line too long:
--help-list - Display list of available options (--help-list-hidden for more)
Traceback (most recent call last):
File "/Users/Owen/remove-braces/clang/docs/tools/./dump_format_help.py", line 63, in <module>
contents = substitute(contents, "FORMAT_HELP", help_text)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Users/Owen/remove-braces/clang/docs/tools/./dump_format_help.py", line 17, in substitute
return re.sub(pattern, "%s", text, flags=re.S) % replacement
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~
TypeError: not enough arguments for format string
```
This patch mainly handles treating `begin` as block openers.
While and for statements will be handled in another patch.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D123450
Relevant issue: https://github.com/llvm/llvm-project/issues/52705
When the `DisableFormat` option of `clang-format` is set to `true` and a JSON file is formatted, the ephemeral variable binding that is added to the top-level object is not removed from the formatted file. For example, this JSON:
```
{
"key": "value"
}
```
Is reformatted to:
```
x = {
"key": "value"
}
```
Which is not valid JSON syntax. This fix avoids the addition of this binding when `DisableFormat` is set to `true`, ensuring that it cannot be left behind when formatting is disabled.
Reviewed By: MyDeveloperDay, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D115769Fixes#52705
This is a bug which gets reported from time to time and we've had multiple attempts to fix it, but don't want to fix it by adding frontEnd to the mix.
This patch aim to find a trivial, but not that sophisticated way of emitting the error without the additional impact of adding libFrontEnd to clang-format.
See {D90121} for analysis of why we don't want those previous attempts
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D111815
This change now generates that list, and the change to clang-format allows
us to run clang-format quickly over these files via the list of files.
clang-format.exe -verbose -n --files=./clang/docs/tools/clang-formatted-files.txt
```
Clang-formating 7926 files
Formatting [1/7925] clang/bindings/python/tests/cindex/INPUTS/header1.h
..
Formatting [7925/7925] utils/bazel/llvm-project-overlay/llvm/include/llvm/Config/config.h
```
This is needed because putting all those files on the command line is too
long, and invoking 7900+ clang-formats is much slower (too slow to be honest)
Using this method it takes on 7.5 minutes (on my machine) to run
`clang-format -n` over all of the files (7925), this should result in us
testing any change quickly and easily.
We should be able to use rerunning this list to ensure that we don't regress
clang-format over a large code base, but also use it to ensure none of the
previous files which were 100% clang-formatted remain so.
(which the LLVM premerge checks should be enforcing)
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D111000
When specifying the alignment direction on the command line ensure
we set up the default ordering.
Fix spelling mistakes in the command-line argument
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D110359
