Revert "[clang-format] SortIncludes should support "@import" lines in Objective-C"

This reverts commit d46fa023caa2db5a9f1e21dd038bcb626261d958.
Regressed include order in some cases with trailing c

Revert "[clang-format] SortIncludes should support "@import" lines in Objective-C"

This reverts commit d46fa023caa2db5a9f1e21dd038bcb626261d958.
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.

show more ...

[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

[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

show more ...

[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 LocalizationChe

[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.

show more ...

[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.c

[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.

show more ...

[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:

[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

show more ...

[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

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
`SourceMana

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

show more ...

[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.ll

[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.

show more ...

[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 IncludeIsM

[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

show more ...

[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 e

[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

show more ...

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

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

show more ...

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 m

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.

show more ...

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 con

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

show more ...

[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 KN

[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

show more ...

[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

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 ne

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

show more ...

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 separat

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

show more ...

[Tooling] Get rid of uses of llvm::Twine::str which is slow. NFC

llvm-svn: 343224

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/

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

show more ...

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/

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

show more ...

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. S

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

show more ...