Skip to content
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

refactor(cli): traversal #3563

Merged
merged 7 commits into from
Aug 4, 2024
Merged

refactor(cli): traversal #3563

merged 7 commits into from
Aug 4, 2024

Conversation

ematipico
Copy link
Member

Summary

Part of #3307

The PR breaks down the traversal into two parts:

  • evaluation
  • handling

The logic of the evaluation is pretty much the same we have today, and at the end instead of calling handle_path, we can a new function called store_path.

Once the evaluation finishes, we call traversal again, but we can a new function called handle, which essentially calls the existing function process_file.

Now that we have this new information, I took the opportunity to add two new verbose diagnostics that show the evaluated paths, and the paths that were changed.

Test Plan

Updated the current snapshosts.

@github-actions github-actions bot added A-CLI Area: CLI A-Core Area: core A-Project Area: project A-Diagnostic Area: diagnostocis A-Changelog Area: changelog labels Aug 1, 2024
@ematipico ematipico requested review from a team August 1, 2024 12:11
Copy link
Member

@Conaclos Conaclos left a comment

Choose a reason for hiding this comment

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

Looks good to me. I left some remarks and suggestions.

CHANGELOG.md Outdated Show resolved Hide resolved
@@ -483,11 +505,16 @@ pub(crate) struct TraversalOptions<'ctx, 'app> {
/// The approximate number of diagnostics the console will print before
/// folding the rest into the "skipped diagnostics" counter
pub(crate) remaining_diagnostics: &'ctx AtomicU32,

/// List of paths that should be processed
pub(crate) evaluated_paths: RwLock<FxHashSet<EvaluatedPath>>,
Copy link
Member

Choose a reason for hiding this comment

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

Just to be sure: why do we need a RWLock here? Have we several processes that “evaluate” files? Or it is just for toggling if a file was fixed? In this last case, we could use an atomic bool?

Copy link
Member Author

Choose a reason for hiding this comment

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

TraversalOptions is sent as a reference across multiple threads. So we need RwLock for two reasons:

  • enable interior mutability when having a &self
  • lock the resource when multiple threads want to update the list

crates/biome_cli/src/execute/traverse.rs Outdated Show resolved Hide resolved
crates/biome_cli/src/reporter/mod.rs Outdated Show resolved Hide resolved
.map(|pattern| pattern as &dyn Display)
.collect();

visitor.record_list(&pattern_list)
Copy link
Member

Choose a reason for hiding this comment

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

In another PR we could certainly accept an impl Iterator in order to avoid the allocation of a Vec.

crates/biome_fs/src/fs.rs Outdated Show resolved Hide resolved
crates/biome_fs/src/fs.rs Outdated Show resolved Hide resolved
@ematipico ematipico merged commit 1582340 into main Aug 4, 2024
13 checks passed
@ematipico ematipico deleted the refactor/cli-traversal branch August 4, 2024 12:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Changelog Area: changelog A-CLI Area: CLI A-Core Area: core A-Diagnostic Area: diagnostocis A-Project Area: project
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants