Skip to content

fmt: improve module detection when formatting imports - #21134

Merged
spytheman merged 4 commits into
vlang:masterfrom
ttytm:fmt/improve-import
Mar 29, 2024
Merged

spytheman merged 4 commits into
vlang:masterfrom
ttytm:fmt/improve-import

Conversation

@ttytm

@ttytm ttytm commented Mar 28, 2024 •

Copy link
Copy Markdown
Member

The PR improves vfmts import detection. It makes it obsolete to keep a special clause to handle modules in a $VMODULES directory. So vmft now should be able can treat all modules accordingly independent of their location.

It also fixes scenarios where vmft adds a src. prefixes to imports. E.g. it would happen in any regular directory when trying to format a module like the src_import that is added to the testdata in this PR. A test was added that covers two scenarios in one - removing the src. prefix and also not adding it an import.

Running the updated test before the fix commit also shows other issues that are resolved with the changes.

@ttytm
ttytm force-pushed the fmt/improve-import branch from 0d78d32 to 7d20cf9 Compare March 28, 2024 23:34
// NOTE: A test that follows a directory strucutre and module naming like this one
// also tests whether vfmt would add a prefix to the import.

import a.ab

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the src. removed at all?

The less vfmt modifies the paths, the better.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you say to allow for both without a formatting error?
For usage of the module both paths work.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer the "one way" philo here when thinking about it.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My main concern about it, is preventing oscillations, where it is removed by one run of vfmt, based on a heuristic, and then added in another run of vfmt, based on another heuristic. It seems to me safer to not modify the imports at all/not have special cases for it.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you say to allow for both without a formatting error?

Imho vfmt should not try to outsmart the person writing the code. It should just format the code as it is written.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing the special case for the vmodules is very important though, and src. is an edge case, that will not be encountered very often, so overall, excellent work.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I would have preferred ALWAYS stripping src.. It is supposed to be a "silent" subdir, same as "modules".

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see the point and concerns. Yeah, since src gets some special treatment already and hopefully isn't too complex to maintain in fmt, giving developers the same code to look at accross code bases might be the right move.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I would have preferred ALWAYS stripping src.. It is supposed to be a "silent" subdir, same as "modules".

There are edge cases where src. is part of the import and required to be kept for the module to work. E.g. importing from a module that is structured like this issue is mentioning #19799. We might improve module lookup so that it works without it then we can always strip src..

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Improving module lookup is long overdue...

@spytheman
spytheman force-pushed the fmt/improve-import branch from 7d20cf9 to 1575f60 Compare March 29, 2024 06:21
@spytheman

Copy link
Copy Markdown
Contributor

(rebased over master)

@spytheman
spytheman merged commit 17d57eb into vlang:master Mar 29, 2024
@ttytm
ttytm deleted the fmt/improve-import branch March 29, 2024 12:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants