Summary

Closes #2827

Configuration

This PR adds support for ignoring files via configuration. The new field has been added to the formatter and the linter sections.

{
	"formatter": {
		"ignore": ["path/to"]
	},
	"linter": {
		"ignore": ["*.ts"]
	}
}

• the functions deserialize_globals and serialize_globals have been renamed to deserialize_set_of_strings and serialize_set_of_strings, so I could apply the same functions for the fields globals and ignore;

Matcher

I forked the create glob locally. I just copied the engine (parser) of the unix shell style patterns, as we are not interested in actual glob function, which does a traversal of the file system. The only changes that I applied to the crate are merely around clippy - it seems there's low activity on the code - and removed some tests. I won't be able to answer technical questions around this crate.

I added license files and credits to the website.

I created a small wrapper called Matcher to add patterns and run the matcher against paths and strings. It also holds a HashMap to track the already checked paths/strings.

There's a catch with this crate: the crate doesn't support patterns like "test.ts". I tested it myself and I think it's intentional. I added some basic check in the Matcher struct to cover this cases, I figured that users might want to ignore single files.

Workspace

The check is done in two places inside the workspace:

• inside the function support_features
• inside a newly created function called is_file_ignored

support_features now returns a new struct which olds an optional reason that explains why the workspace doesn't support a certain file. Before, we were not distinguish the reason why a file couldn't be supported, and this caused some issue that are not fixed. If you check the snapshots, you might notice some deletions of some code that was out of place.

We now use an enum called UnsupportedReason which tells the traversal/LSP why a file is not supported, and based on that they can react accordingly.

is_file_ignored is in the workspace Workspace. This new function is now used in most of all functions that act on some files, I am not sure if I should extend the functionality also on get_syntax_tree and get_control_flow_graph.

The usage of is_file_ignored has been placed before the parsing starts. There's no need to actually parse a file if it's ignored.

When a file is ignored, we intentionally return an error. It's up to the clients to decide to ignore the error or deal with it. This is a pattern we already apply in case a file is not supported.

Test Plan

I added two new tests for the CLI.

I manually built the VSCode extension and made sure that I don't see diagnostics if a file is ignored. And also if the file doesn't get formatted.