LSP to resolve custom include paths (e.g. Hardhat)

[christianparpart]

This PR is WIP, but it will fix #12833 later on.

Big question is, how do we want to tell solc --lsp where to look for include paths. I remember there was some project file format that does include that information, but what was that? @cameel, do you remember?

Checklist:

• factor our file path resolving in FileRepository: tryResolvePath(.)
• fix sourceUnitNameToUri() by making use of new path resolver.
• custom include paths via JSON settings object
• always add {projectRoot}/node_modules to include paths (vscode-solidity is doing that too and users are used to it)

[cameel]

I remember there was some project file format that does include that information, but what was that? @cameel, do you remember?

Do you mean the dappfile (EIP 82)? Or one of the config files actually used by frameworks?

[christianparpart]

I remember there was some project file format that does include that information, but what was that? @cameel, do you remember?

Do you mean the dappfile (EIP 82)? Or one of the config files actually used by frameworks?

ah right thanks! Dappfile is what I remembered, but this time, I in fact meant a framework that introduced a file that is now also supported by another one. I am talking vaguely because I forgot the names. ;-(

I might look into Dappfile though.

[christianparpart]

@cameel if we can't come up with something immediately, what do you think about adding a CLI option, such as --lsp-search-paths PATH,.... NB: We once agreed in explicitly not messing with standard-json or related CLI args, as these are in fact two different topics, IIRC.

[cameel]

ah right thanks! Dappfile is what I remembered, but this time, I in fact meant a framework that introduced a file that is now also supported by another one. I am talking vaguely because I forgot the names. ;-(

Oh, you meant remappings.txt (#12603). But it's not really for include paths. It's for remappings (though in practice they get used to get the same effect).

[christianparpart]

if we can't come up with something immediately, what do you think about adding a CLI option,

Why not just support --include-paths instead of adding a new arg?

I can do that. thanks. But I am still hoping for some kind of auto-configuration, where users do not need to do too much.

Suppose you are working in more than one project, and they all do not necessarily share the same include paths.

I think we could auto-detect at least the well known frameworks and adjust the include paths accordingly (on top of manually added ones, if added). What do you think, @cameel ?

[Marenz]

In the commit with the descrp. [lsp] Fixes sourceUnitNameToUri() path path resolving in relation to ... …include paths being used.
Maybe one path is enough in the commit message? :P

done

[narghev]

Hi, just had this problem on nvim with newly installed version of solc using brew.
Version: 0.8.15+commit.e14f2714.Darwin.appleclang

Wanted to check if this is released already or not.

Edit: Checked and the commit with hash e14f2714 thus the v0.8.15 was released on Jun 15th which is before this merge. Is this going to be included in 0.8.16?

[cameel]

Yes, this will go into 0.8.16, which we are releasing tomorrow.