|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init |
|
| #
03c59765 |
| 28-Jan-2022 |
Martin Probst <[email protected]> |
clang-format: [JS] sort import aliases. Users can define aliases for long symbols using import aliases:
import X = A.B.C;
Previously, these were unhandled and would terminate import sorting.
Wi
clang-format: [JS] sort import aliases. Users can define aliases for long symbols using import aliases:
import X = A.B.C;
Previously, these were unhandled and would terminate import sorting.
With this change, aliases sort as their own group, coming last after all
other imports.
Aliases are not sorted within their group, as they may reference each
other, so order is significant.
This reverts commit f750c3d95a0c8bf1d21380ae753fce12010a7561. It fixes
the msan issue by not parsing past the end of the line when handling
import aliases.
Differential Revision: https://reviews.llvm.org/D118446
show more ...
|
| #
f750c3d9 |
| 28-Jan-2022 |
Vitaly Buka <[email protected]> |
Revert "clang-format: [JS] sort import aliases."
Triggers MSAN report.
This reverts commit c6d5efb5d98093c4bd7578b2ea52c9032d20dea3.
|
| #
c6d5efb5 |
| 27-Jan-2022 |
Martin Probst <[email protected]> |
clang-format: [JS] sort import aliases.
Users can define aliases for long symbols using import aliases:
import X = A.B.C;
Previously, these were unhandled and would terminate import sorting.
W
clang-format: [JS] sort import aliases.
Users can define aliases for long symbols using import aliases:
import X = A.B.C;
Previously, these were unhandled and would terminate import sorting.
With this change, aliases sort as their own group, coming last after all
other imports.
Aliases are not sorted within their group, as they may reference each
other, so order is significant.
Revision URI: https://reviews.llvm.org/D118361
show more ...
|
|
Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3 |
|
| #
69ecd248 |
| 20-Jan-2022 |
Marek Kurdej <[email protected]> |
[clang-format] Indicate source location on test failure. NFC.
|
|
Revision tags: llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2 |
|
| #
63042d46 |
| 11-Jun-2021 |
Martin Probst <[email protected]> |
clang-format: [JS] don't sort named imports if off.
The previous implementation would accidentally still sort the individual
named imports, even if the module reference was in a clang-format off
blo
clang-format: [JS] don't sort named imports if off.
The previous implementation would accidentally still sort the individual
named imports, even if the module reference was in a clang-format off
block.
Differential Revision: https://reviews.llvm.org/D104101
show more ...
|
|
Revision tags: llvmorg-12.0.1-rc1 |
|
| #
b2780cd7 |
| 29-Apr-2021 |
Martin Probst <[email protected]> |
clang-format: [JS] handle "off" in imports
Previously, the JavaScript import sorter would ignore `// clang-format
off` and `on` comments. This change fixes that. It tracks whether
formatting is enab
clang-format: [JS] handle "off" in imports
Previously, the JavaScript import sorter would ignore `// clang-format
off` and `on` comments. This change fixes that. It tracks whether
formatting is enabled for a stretch of imports, and then only sorts and
merges the imports where formatting is enabled, in individual chunks.
This means that there's no meaningful total order when module references are mixed
with blocks that have formatting disabled. The alternative approach
would have been to sort all imports that have formatting enabled in one
group. However that raises the question where to insert the
formatting-off block, which can also impact symbol visibility (in
particular for exports). In practice, sorting in chunks probably isn't a
big problem.
This change also simplifies the general algorithm: instead of tracking
indices separately and sorting them, it just sorts the vector of module
references. And instead of attempting to do fine grained tracking of
whether the code changed order, it just prints out the module references
text, and compares that to the previous text. Given that source files
typically have dozens, but not even hundreds of imports, the performance
impact seems negligible.
Differential Revision: https://reviews.llvm.org/D101515
show more ...
|
| #
fbc6f42d |
| 22-Apr-2021 |
Martin Probst <[email protected]> |
clang-format: [JS] do not merge side-effect imports.
The if condition was testing the current element, but
forgot to check the previous element (doh), so it
would fail depending on sort order of the
clang-format: [JS] do not merge side-effect imports.
The if condition was testing the current element, but
forgot to check the previous element (doh), so it
would fail depending on sort order of the imports.
Differential Revision: https://reviews.llvm.org/D101020
show more ...
|
| #
3d4a6037 |
| 19-Apr-2021 |
Martin Probst <[email protected]> |
clang-format: [JS] do not merge imports and exports.
Previously, clang-format would erroneously merge import and export
statements. These need to be kept separate, as the semantics differ.
Differen
clang-format: [JS] do not merge imports and exports.
Previously, clang-format would erroneously merge import and export
statements. These need to be kept separate, as the semantics differ.
Differential Revision: https://reviews.llvm.org/D100752
show more ...
|
| #
4d195f1b |
| 14-Apr-2021 |
Martin Probst <[email protected]> |
review comments
track symbol merge status in references to avoid excesive rewrites
|
| #
d45df0d2 |
| 14-Apr-2021 |
Martin Probst <[email protected]> |
clang-format: [JS] merge import lines.
Multiple lines importing from the same URL can be merged:
import {X} from 'a';
import {Y} from 'a';
Merge to:
import {X, Y} from 'a';
This chan
clang-format: [JS] merge import lines.
Multiple lines importing from the same URL can be merged:
import {X} from 'a';
import {Y} from 'a';
Merge to:
import {X, Y} from 'a';
This change implements this merge operation. It takes care not to merge in
various corner case situations (default imports, star imports).
Differential Revision: https://reviews.llvm.org/D100466
show more ...
|
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
| #
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <[email protected]> |
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 ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2 |
|
| #
4bf1d7ad |
| 01-Aug-2017 |
Martin Probst <[email protected]> |
clang-format: [JS] support default imports.
Summary: Formerly, `import {default as X} from y;` would not be recognized as an import.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differenti
clang-format: [JS] support default imports.
Summary: Formerly, `import {default as X} from y;` would not be recognized as an import.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D36132
llvm-svn: 309697
show more ...
|
|
Revision tags: llvmorg-5.0.0-rc1 |
|
| #
93008f01 |
| 18-Jul-2017 |
Martin Probst <[email protected]> |
clang-format: [JS] Correctly format JavaScript imports with long module paths
Currently the `UnwrappedLineParser` fails to correctly unwrap JavaScript
imports where the module path is not on the sam
clang-format: [JS] Correctly format JavaScript imports with long module paths
Currently the `UnwrappedLineParser` fails to correctly unwrap JavaScript
imports where the module path is not on the same line as the `from` keyword.
For example:
import {A} from
'some/path/longer/than/column/limit/module.js';```
This causes issues when in the middle a list of imports because the formatter
thinks it has reached the end of the imports, and therefore will not sort any
imports lower in the list.
The formatter will, however, split the `from` keyword and the module path if
the path exceeds the column limit, which triggers the issue the next time the
file is formatted.
Patch originally by Jared Neil - thanks!
Differential Revision: https://reviews.llvm.org/D34920
llvm-svn: 308306
show more ...
|
|
Revision tags: llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1 |
|
| #
63014581 |
| 19-Sep-2016 |
Martin Probst <[email protected]> |
clang-format: [JS] Fix line breaks before comments when sorting imports.
Summary:
Previously, clang-format would always insert an additional line break after the
import block if the main body starte
clang-format: [JS] Fix line breaks before comments when sorting imports.
Summary:
Previously, clang-format would always insert an additional line break after the
import block if the main body started with a comment, due to loosing track of
the first non-import line.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D24708
llvm-svn: 281888
show more ...
|
| #
6918dcaf |
| 02-Sep-2016 |
Martin Probst <[email protected]> |
clang-format: [JS] handle default bindings in imports.
Summary:
Default imports appear outside of named bindings in curly braces:
import A from 'a';
import A, {symbol} from 'a';
Reviewers: dja
clang-format: [JS] handle default bindings in imports.
Summary:
Default imports appear outside of named bindings in curly braces:
import A from 'a';
import A, {symbol} from 'a';
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D23973
llvm-svn: 280486
show more ...
|
| #
b480ffbc |
| 02-Sep-2016 |
Martin Probst <[email protected]> |
clang-format: [JS] Sort all JavaScript imports if any changed.
Summary:
User feedback is that they expect *all* imports to be sorted if any import was
affected by a change, not just imports up to th
clang-format: [JS] Sort all JavaScript imports if any changed.
Summary:
User feedback is that they expect *all* imports to be sorted if any import was
affected by a change, not just imports up to the first non-affected line, as
clang-format currently does.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D23972
llvm-svn: 280485
show more ...
|
|
Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1 |
|
| #
4f8d9943 |
| 11-Jul-2016 |
Eric Liu <[email protected]> |
Make tooling::applyAllReplacements return llvm::Expected<string> instead of empty string to indicate potential error.
Summary:
return llvm::Expected<> to carry error status and error information.
Th
Make tooling::applyAllReplacements return llvm::Expected<string> instead of empty string to indicate potential error.
Summary:
return llvm::Expected<> to carry error status and error information.
This is the first step towards introducing "Error" into tooling::Replacements.
Reviewers: djasper, klimek
Subscribers: ioeric, klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D21601
llvm-svn: 275062
show more ...
|
| #
2a19454a |
| 09-Jul-2016 |
Martin Probst <[email protected]> |
clang-format: [JS] Sort imports case insensitive.
Summary: ASCII case sorting does not help finding imported symbols quickly, and it is common to have e.g. class Foo and function fooFactory exported
clang-format: [JS] Sort imports case insensitive.
Summary: ASCII case sorting does not help finding imported symbols quickly, and it is common to have e.g. class Foo and function fooFactory exported/imported from the same file.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D22146
llvm-svn: 274977
show more ...
|
| #
a8c9d154 |
| 09-Jul-2016 |
Martin Probst <[email protected]> |
clang-format: [JS] support trailing commas in imports.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D22147
llvm-svn: 274976
|
| #
0cd74ee8 |
| 13-Jun-2016 |
Martin Probst <[email protected]> |
clang-format: [JS] Introduce JavaScriptWrapImports option.
Summary:
When turned on, clang-format wraps JavaScript imports (and importing exports),
instead of forcing the entire import statement onto
clang-format: [JS] Introduce JavaScriptWrapImports option.
Summary:
When turned on, clang-format wraps JavaScript imports (and importing exports),
instead of forcing the entire import statement onto one line.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D21273
llvm-svn: 272558
show more ...
|
| #
6f43efbd |
| 08-Jun-2016 |
Martin Probst <[email protected]> |
clang-format: [JS] fix an assertion failure caused by shrinking sources.
Summary:
The JavaScript import sorter has a corner condition that can cause the overall
source text length to shrink. This ch
clang-format: [JS] fix an assertion failure caused by shrinking sources.
Summary:
The JavaScript import sorter has a corner condition that can cause the overall
source text length to shrink. This change circumvents the issue by appending
trailing space in the line after the import blocks to match at least the
previous source code length.
This needs a better long term fix, but this fixes the immediate issue.
Reviewers: alexeagle, djasper
Subscribers: klimek
Differential Revision: http://reviews.llvm.org/D21108
llvm-svn: 272142
show more ...
|
|
Revision tags: llvmorg-3.8.1, llvmorg-3.8.1-rc1 |
|
| #
081f176a |
| 01-Jun-2016 |
Martin Probst <[email protected]> |
clang-format: [JS] Sort imported symbols.
Summary: E.g. sort `import {b, a} from 'x';` into `import {a, b} from 'x';`.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: h
clang-format: [JS] Sort imported symbols.
Summary: E.g. sort `import {b, a} from 'x';` into `import {a, b} from 'x';`.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D20798
llvm-svn: 271400
show more ...
|
| #
c4a0dd49 |
| 20-May-2016 |
Martin Probst <[email protected]> |
clang-format: [JS] sort ES6 imports.
Summary:
This change automatically sorts ES6 imports and exports into four groups:
absolute imports, parent imports, relative imports, and then exports. Exports
clang-format: [JS] sort ES6 imports.
Summary:
This change automatically sorts ES6 imports and exports into four groups:
absolute imports, parent imports, relative imports, and then exports. Exports
are sorted in the same order, but not grouped further.
To keep JS import sorting out of Format.cpp, this required extracting the
TokenAnalyzer infrastructure to separate header and implementation files.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D20198
llvm-svn: 270203
show more ...
|