[LS] Add InternalEVM stdlib Contract

[jribbink]

Issue to be solved

Because the InternalEVM standard library value is not a part of the Cadence runtime, but rather, part of the FVM, it is not known to the language server. It is, however, valid to the FVM & developers wishing to get code-analysis while using the EVM/InternalEVM contract will be unable to.

This is a more general problem than just the InternalEVM contract, however, it seems to me that the InternalEVM contract is the only one that needs to be considered for the time being.

(related onflow/vscode-cadence#574)

Suggested Solution

Add an additional option to the server, WithStandardLibraryValues, or similar, that would accept additional values that may be declared as a part of the stdlib.

This could be used as a part of the LS flow integration, where the FVM standard library values are specified. This way the FVM-specific stdlib stays decoupled from the Cadence LS implementation itself.

[turbolent]

InternalEVM is an implementation detail, only used and accessible in the EVM contract.

While it is annoying that the EVM contract (https://github.com/onflow/flow-go/blob/master/fvm/evm/stdlib/contract.cdc) cannot be successfully checked/developed with the LS, this should only really be a problem for contributors to flow-go/FVM, no?

[jribbink]

InternalEVM is an implementation detail, only used and accessible in the EVM contract.

While it is annoying that the EVM contract (https://github.com/onflow/flow-go/blob/master/fvm/evm/stdlib/contract.cdc) cannot be successfully checked/developed with the LS, this should only really be a problem for contributors to flow-go/FVM, no?

Unfortunately, the problem actually surfaces for developers importing the EVM contract. What happens is that, because the EVM contract produces checker errors (by relying on InternalEVM), the import cannot be resolved, so it is inaccessible within the user's code.

I guess the other workaround here is trying to ignore errors when checking EVM contract, although I worry that it may be a slippery slope trying to write custom import rules for a particular imported contract.

[turbolent]

Unfortunately, the problem actually surfaces for developers importing the EVM contract. What happens is that, because the EVM contract produces checker errors (by relying on InternalEVM), the import cannot be resolved, so it is inaccessible within the user's code.

Ah, that makes sense! I hadn't considered that even for code importing EVM this is an issue. 👍