Add VSCode command of generating verible.filelist at the root folder

[Hamster5295]

What's the Problem?

The verible.filelist is essential for LSP to function with multiple files, i.e. finding the definition of a module from another source.
However, it's not documented in the VSCode Extension README and neither does a command exist for generating the filelist, which may cause confusion for users who is not quite familiar with the Verible toolkit.

What has been done in this PR?

• A VSCode command is added, providing the function of collecting all the files with specific extensions (.v, .sv, .vh and .svh are set as default) and generating the verible.filelist at the project root, then restarting the language server so that the new filelist can be loaded.
• A new setting entry is added, enabling users to specify which extensions are going to be collected as filelist.
• A Quick Start section is added to the README.md, helping new users understand how to use the verible language server with VSCode properly.

[hzeller]

mmh, I think instead of adding more complexity to the various editor configuration which makes it fragile and hard-to-maintain, we should have a flag to the verible language server to automatically find the files instead.

Can you file an issue with that, essentially pointing out the problem you pose above ?

[Hamster5295]

mmh, I think instead of adding more complexity to the various editor configuration which makes it fragile and hard-to-maintain

That's the truth in constructing clean and pure code infrastructures that provide fundamental functions, i.e. the language server itself. 🐱
However, it might not be the case when it comes to the VSCode extension. VSCode, along with its easy-to-use user interfaces, has attracted a large sum of users who are not familiar with those fundations, i.e. a Windows user who has little knowledge about cmd and PowerShell, letting alone the find . -name "*.sv" -o -name "*.svh" -o -name "*.v" | sort > verible.filelist shell script.
Thus, I find it necessary to provide guide and handy tools for them, even though it might introduce more complexity. After all, we're targeting on the Users instead of the System in this case. 😸

we should have a flag to the verible language server to automatically find the files instead

That's a awesome solution! But I think filelists are still necessary, as it should be the users' freedom to choose which file is going to be indexed and which is not.
Maybe there can be a flag with an argument, specifying whether the language server should scan the whole project, or use a provided filelist.

Can you file an issue with that, essentially pointing out the problem you pose above ?

Here is one: #2177
There're not many issues posed here, but I think the problem still exists.
Users who fail to look into the documents in this repo might not even have the sense that an issue can be posed when problem occurs at open-source projects. They would just comment: "Ah, another VSCode extension that is not working properly" and uninstall it. 😿

[corco]

I also have issues with verible.filelist. The file is awkward in large project as you often want to exclude files (like netlists) and you need to remember to update it when files are added/renamed.

I personally would like verible.filelist:

• To support glob style path and directory watching. 'hdl/**' would replace 95% of verible.filelist
• To support exclusion from glob file. This solve 95% of the remaining 5%. Note that this is what svlangserver does.
• To support composition by including other verible.filelist. That way every IP Core could have it's own verible.filelist and toplevel project reuse them.

I think supporting glob and defaulting to .sv|.svh|.v|.vh if verible.filelist is missing is a good first step.

As an aside, I really like how slang deal with that problem. They make their file be able to specify command line arguments and not just list individual files. They also support listing only directories and include individual files based on parsing and naming convention (for example, a file with import my_pkg::MY_CONST; would start a search for my_pkg.sv and automatically parse it).