Commit Graph

25 Commits

Author SHA1 Message Date
Kazu Hirata 5891420e68 [clang] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated.  The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-03 11:54:46 -08:00
owenca 7cbc920669 [clang-format][NFC] Clean up class HeaderIncludes and Format.cpp
Differential Revision: https://reviews.llvm.org/D134852
2022-10-05 21:54:40 -07:00
Krasimir Georgiev e8cc7490d2 Revert "[clang-format] SortIncludes should support "@import" lines in Objective-C"
This reverts commit d46fa023ca.
Regressed include order in some cases with trailing comments, see the
comments on https://reviews.llvm.org/D121370. Will add a regression test
in a follow-up commit.
2022-04-28 11:00:32 +02:00
Konrad Kleine d46fa023ca [clang-format] SortIncludes should support "@import" lines in Objective-C
Fixes [[ https://github.com/llvm/llvm-project/issues/38995 | #38995 ]]

This is an attempt to modify the regular expression to identify
`@import` and `import` alongside the regular `#include`. The challenging
part was not to support `@` in addition to `#` but how to handle
everything that comes after the `include|import` keywords. Previously
everything that wasn't `"` or `<` was consumed. But as you can see in
this example from the issue #38995, there is no `"` or `<` following the
keyword:

```
@import Foundation;
```

I experimented with a lot of fancy and useful expressions in [this
online regex tool](https://regex101.com) only to find out that some
things are simply not supported by the regex implementation in LLVM.

 * For example the beginning `[\t\ ]*` should be replacable by the
   horizontal whitespace character `\h*` but this will break the
   `SortIncludesTest.LeadingWhitespace` test.

That's why I've chosen to come back to the basic building blocks.

The essential change in this patch is the change from this regular
expression:

```
^[\t\ ]*#[\t\ ]*(import|include)[^"<]*(["<][^">]*[">])
        ~                              ~~~~~~~~~~~~~~
        ^                              ^
        |                              |
        only support # prefix not @    |
                                       only support "" and <> as
delimiters
                                       no support for C++ modules and ;
                                       ending. Also this allows for ">
                                       or <" or "" or <> which all seems
                                       either off or wrong.
```

to this:

```
^[\t\ ]*[@#][\t\ ]*(import|include)([^"]*("[^"]+")|[^<]*(<[^>]+>)|[\t\
]*([^;]+;))
        ~~~~                        ~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
~~~~~~~~~~~~~~
        ^                                 ^           ^       ^       ^
        |                                 |           |       |       |
        Now support @ and #.            Clearly support "" and <> as
well as an
                                        include name without enclosing
characters.
                                        Allows for no mixture of "> or
<" or
                                        empty include names.

```

Here is how I've tested this patch:

```
ninja clang-Format
ninja FormatTests
./tools/clang/unittests/Format/FormatTests
--gtest_filter=SortIncludesTest*
```

And if that worked I doubled checked that nothing else broke by running
all format checks:

```
./tools/clang/unittests/Format/FormatTests
```

One side effect of this change is it should partially support
[C++20 Module](https://en.cppreference.com/w/cpp/language/modules)
`import` lines without the optional `export` in front. Adding
this can be a change on its own that shouldn't be too hard. I say
partially because the `@` or `#` are currently *NOT* optional in the
regular expression.

I see an opportunity to optimized the matching to exclude `@include` for
example. But eventually these should be caught by the compiler, so...

With my change, the matching group is not at a fixed position any
longer. I decided to
choose the last match (group) that is not empty.

Reviewed By: HazardyKnusperkeks

Differential Revision: https://reviews.llvm.org/D121370
2022-04-20 07:03:35 +00:00
Dawid Jurczak b3e2dac27c [NFC] Don't pass temporary LangOptions to Lexer
Since https://reviews.llvm.org/D120334 we shouldn't pass temporary LangOptions to Lexer.
This change fixes stack-use-after-scope UB in LocalizationChecker found by sanitizer-x86_64-linux-fast buildbot
and resolve similar issue in HeaderIncludes.
2022-02-28 20:43:28 +01:00
Martin Storsjö e5c7c171e5 [clang] Rename StringRef _lower() method calls to _insensitive()
This is mostly a mechanical change, but a testcase that contains
parts of the StringRef class (clang/test/Analysis/llvm-conventions.cpp)
isn't touched.
2021-06-25 00:22:01 +03:00
mydeveloperday 8668eae2ad [clang-format] Add option for case sensitive regexes for sorted includes
I think the title says everything.

Reviewed By: MyDeveloperDay

Patch By:  HazardyKnusperkeks

Differential Revision: https://reviews.llvm.org/D91507
2020-12-05 16:33:21 +00:00
Haojian Wu 84048e234f [format] foo.<name>.h should be the main-header for foo.<name>.cc
This fixes a regression introduced in https://reviews.llvm.org/D88640.

Differential Revision: https://reviews.llvm.org/D89783
2020-10-20 13:27:02 +02:00
Duncan P. N. Exon Smith b3eff6b7bb Lexer: Update the Lexer to use MemoryBufferRef, NFC
Update `Lexer` / `Lexer::Lexer` to use `MemoryBufferRef` instead of
`MemoryBuffer*`. Callers that were acquiring a `MemoryBuffer*` via
`SourceManager::getBuffer` were updated, such that if they checked
`Invalid` they use `getBufferOrNone` and otherwise `getBufferOrFake`.

Differential Revision: https://reviews.llvm.org/D89398
2020-10-19 19:10:21 -04:00
Haojian Wu c1b209cc61 [Format] Don't treat compound extension headers (foo.proto.h) as foo.cc main-file header.
We receive internal bugs about this false positives after D86597.

Differential Revision: https://reviews.llvm.org/D88640.
2020-10-01 19:57:57 +02:00
Sam McCall 266825620c [Tooling][Format] Treat compound extensions (foo.bar.cc) as matching foo.h
Motivating use case is ".cu.cc" extensions used in some bazel projects.

Alternative is to work around this with IncludeIsMainRegex in styles.
I proposed this approach because it seems like a better default.

Differential Revision: https://reviews.llvm.org/D86597
2020-08-27 15:24:17 +02:00
Kadir Cetinkaya ea8e71c3da
[clang][HeaderInsert] Do not treat defines with values as header guards
This was resulting in inserting headers at bogus locations, see
https://github.com/ycm-core/YouCompleteMe/issues/3736 for an example.

Differential Revision: https://reviews.llvm.org/D85590
2020-08-11 16:02:11 +02:00
Reid Kleckner e08464fb45 Avoid including FileManager.h from SourceManager.h
Most clients of SourceManager.h need to do things like turning source
locations into file & line number pairs, but this doesn't require
bringing in FileManager.h and LLVM's FS headers.

The main code change here is to sink SM::createFileID into the cpp file.
I reason that this is not performance critical because it doesn't happen
on the diagnostic path, it happens along the paths of macro expansion
(could be hot) and new includes (less hot).

Saves some includes:
    309 -    /usr/local/google/home/rnk/llvm-project/clang/include/clang/Basic/FileManager.h
    272 -    /usr/local/google/home/rnk/llvm-project/clang/include/clang/Basic/FileSystemOptions.h
    271 -    /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/VirtualFileSystem.h
    267 -    /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/FileSystem.h
    266 -    /usr/local/google/home/rnk/llvm-project/llvm/include/llvm/Support/Chrono.h

Differential Revision: https://reviews.llvm.org/D75406
2020-03-11 13:53:12 -07:00
Benjamin Kramer adcd026838 Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.

This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.

This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-28 23:25:25 +01:00
mydeveloperday 335ac2eb66 Allow additional file suffixes/extensions considered as source in main include grouping
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
2019-11-12 21:26:52 +00:00
Paul Hoad 52e44b1423 [clang-format] Modified SortIncludes and IncludeCategories to priority for sorting #includes within the Group Category.
Summary:
This new Style rule is made as a part of adding support for NetBSD KNF in clang-format. NetBSD have it's own priority of includes which should be followed while formatting NetBSD code. This style sorts the Cpp Includes according to the priorities of NetBSD, as mentioned in the [Style Guide](http://cvsweb.netbsd.org/bsdweb.cgi/src/share/misc/style?rev=HEAD&content-type=text/x-cvsweb-markup)
 The working of this Style rule shown below:

**Configuration:**
This revision introduces a new field under IncludeCategories named `SortPriority` which defines the priority of ordering the `#includes` and the `Priority` will define the categories for grouping the `#include blocks`.

Reviewers: cfe-commits, mgorny, christos, MyDeveloperDay

Reviewed By: MyDeveloperDay

Subscribers: lebedev.ri, rdwampler, christos, mgorny, krytarowski

Patch By: Manikishan

Tags: #clang, #clang-format

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

llvm-svn: 372919
2019-09-25 20:33:01 +00:00
Eric Liu 2473961305 [Tooling] Handle #pragma once header guard in include insertion.
Reviewers: ilya-biryukov

Subscribers: cfe-commits

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

llvm-svn: 352503
2019-01-29 14:40:01 +00:00
Chandler Carruth 2946cd7010 Update the file headers across all of the LLVM projects in the monorepo
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
2019-01-19 08:50:56 +00:00
Erik Pilkington fa98390b3c NFC: Remove the ObjC1/ObjC2 distinction from clang (and related projects)
We haven't supported compiling ObjC1 for a long time (and never will again), so
there isn't any reason to keep these separate. This patch replaces
LangOpts::ObjC1 and LangOpts::ObjC2 with LangOpts::ObjC.

Differential revision: https://reviews.llvm.org/D53547

llvm-svn: 345637
2018-10-30 20:31:30 +00:00
Eric Liu bb898704e9 [Tooling] Get rid of uses of llvm::Twine::str which is slow. NFC
llvm-svn: 343224
2018-09-27 14:50:24 +00:00
Eric Liu 44564ac7eb Reland "Move #include manipulation code to new lib/Tooling/Inclusions."
This reverts commit r333534 (i.e. reland r332720) after fixing module build.

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

llvm-svn: 333874
2018-06-04 09:04:12 +00:00
Eric Liu cfd01f94b2 Revert "Reland "Move #include manipulation code to new lib/Tooling/Inclusions.""
This reverts commit r333532. Revert for now to fix an internal bot issue.

llvm-svn: 333534
2018-05-30 12:09:58 +00:00
Eric Liu 4f20e9de0a Reland "Move #include manipulation code to new lib/Tooling/Inclusions."
This reverts commit r332751 (i.e. reland r332720) after fixing module
build.

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

llvm-svn: 333532
2018-05-30 11:51:48 +00:00
Eric Liu 1edf4bc68c Revert "Move #include manipulation code to new lib/Tooling/Inclusions."
This reverts commit r332720. This break build bot with modules. Need to
investigate. Revert the change to unbreak bots.

llvm-svn: 332751
2018-05-18 18:33:08 +00:00
Eric Liu e0a3f5b1a9 Move #include manipulation code to new lib/Tooling/Inclusions.
Summary:
clangToolingCore is linked into almost everything (incl. clang), but
not few tools need #include manipulation at this point. So pull this into a
separate library in Tooling.

Reviewers: ilya-biryukov

Subscribers: klimek, mgorny, cfe-commits, thakis

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

llvm-svn: 332720
2018-05-18 14:16:37 +00:00