When the imported symbol is exactly "template" the sorting is disabled.
"import {template} from x;" is not recognized as an import.
Differential Revision: https://reviews.llvm.org/D61663
Contributed by @jankuehle!
https://reviews.llvm.org/D150116 introduced a bug. `export type X = Y` was considered an export declaration and took part in import sorting. This is not correct. With this change `export type X = Y` properly terminates import sorting.
Reviewed By: krasimir
Differential Revision: https://reviews.llvm.org/D150563
Contributed by @jankuehle!
Users can choose to only import/export the type of the symbol (not value nor namespace) by adding a `type` keyword, e.g.:
```
import type {x} from 'y';
import {type x} from 'y';
export type {x};
export {type x};
```
Previously, this was not handled and would:
- Terminate import sorting
- Remove the space before the curly bracket in `export type {`
With this change, both formatting and import sorting work as expected.
Reviewed By: MyDeveloperDay, krasimir
Differential Revision: https://reviews.llvm.org/D150116
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
