-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(forge fmt
): sorting of imports adds newlines in groups
#7944
Comments
Pinging @meetmangukiya who authored #5442 and @mattsse who contributed too |
Another consequence of this is that any comment at the end of an import statement line (not on a separate line) is moved to a random position after formatting. (e.g. in my case on the Original: // SPDX-License-Identifier: MIT
pragma solidity 0.8.20;
import { ERC20 } from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import { ERC20Permit } from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol";
import { ERC20Burnable } from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol"; // test
import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import { IERC20Permit } from "@openzeppelin/contracts/token/ERC20/extensions/IERC20Permit.sol";
import { AccessControl } from "@openzeppelin/contracts/access/AccessControl.sol"; Formatted: // SPDX-License-Identifier: MIT
pragma solidity 0.8.20; // test
import { AccessControl } from "@openzeppelin/contracts/access/AccessControl.sol";
import { ERC20 } from "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import { ERC20Burnable } from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol";
import { ERC20Permit } from "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol";
import { IERC20Permit } from "@openzeppelin/contracts/token/ERC20/extensions/IERC20Permit.sol"; |
I took a bit of time to look further into this, and I think it's really not the best idea to do the sorting at the CST level. The formatter relies on offsets into the original source to function, and reordering the nodes, even if we adjust the offsets (which is a pain to do), would still leave the CST divergent from the source. What about performing the sorting at the string level before it gets parsed by Also, since the formatter preferences are not currently passed to the parse function, this would also require some refactoring. I am thinking about making a very simple parser with To avoid reallocating maybe we could even try to get a sorted output that is smaller or equal to the length of the original imports group, padding it to its original length with whitespace if necessary, so that the rest of the string doesn't need to move. Alternatively a string rope (with |
yeah perhaps we'd need two passes here, first sort, then parse again, maybe |
Brilliant if you agree @mattsse ! I could work on this over the next few days, maybe it will take a few days to a couple of weeks. I was thinking to use I refactored the inputs to the parser to be a |
please don't waste your time writing yet another solidity parser :) cc @DaniPopes I assume we could fix this particular issue with a "hacky" preprocessing step that does sorting first or smarter loc updates |
Right, I was only saying this because for reordering imports it feels wasteful to parse the full language, and also it's much easier to work with an AST. |
forge fmt
): sorting of imports adds newlines in groups
Component
Forge
Have you ensured that all of these are up to date?
What version of Foundry are you on?
master
What command(s) is the bug in?
forge fmt
Operating System
Linux
Describe the bug
Imports sorting sometimes adds empty lines in the middle of a group. Repro:
Output:
As you can see, there is an empty line before the last element.
I dug a bit into the formatter code and I noticed that the
Loc::File
offsets are not updated when re-ordering theSourceUnitPart
s in:foundry/crates/fmt/src/formatter.rs
Lines 1696 to 1705 in 467aff3
Since the rest of the formatter makes heavy use of those locations, I assumed they are important.
I attempted a dirty fix by re-writing the
Loc
start and end offsets according to the new ordering and that seems to fix the bug described above, but my dirty fix does not take into account the spacing between the variousSourceUnitPart
s (due to semicolon and line break, or a potential comment on the same line).Maybe someone smarter can create a better fix? Also, I haven't even attempted to update the location of the renames in the
Import::Rename
variant, but that should also probably be done?The text was updated successfully, but these errors were encountered: