Bug fix: Disallow non-absolute non-relative FS imports

[haltman-at]

This PR addresses #4161, sort of, by just disallowing such imports.

So, the problem in #4161 regards what happens when you use FS-resolved direct imports that are neither absolute nor explicitly relative. The problem is, there's not really any reasonable way to make these work.

Truffle tries to give each source a canonical path -- not necessarily a file path, but a path it's going to pass with it to solc. Normally when making file-system imports, you use a relative path. This works with Truffle and with Solidity; Truffle can find the source you're looking for to pass to solc, and Solidity can resolve the relative path among the sources you pass to it. This also works with non-FS imports for the same reasons.

But what if you use a direct import? In this case, Solidity performs no resolution of relative paths.

Now, if the direct import is absolute, or isn't FS-resolved at all, then this isn't a problem, because the imported path, being given in full, will match what we pass to solc. (Although, absolute file imports might have problems, if, say you're on Windows; but you're not really supposed to use those in the first place although I haven't explicitly disallowed them here.) But what if it's neither absolute, nor explicitly relative?

Then we get a mismatch: The path where Solidity looks for the import will be a shortened path, whereas the path we pass to solc for it will be the full path. It won't find it! Alternatively, we may end up passing it under both paths, which causes other problems.

There's not really any reasonable way for us to resolve this (unless we're willing to drop the project:/ prefix, and have just e.g. contracts/C.sol instead of project:/contracts/C.sol). Because regardless of what we do, solc will look at the short path, not the path we want. So either we have to make the short path the canonical path (and drop project:/ as just mentioned), or we have to disallow such things. (Or we have to go to substantially more effort and try actually rewriting import statements or something, which I don't think we're about to do.)

Note that the existing behavior for such imports was for them to be resolved relative to the directory the command was running in, so they wouldn't have worked consistently anyway. So, hopefully, this change isn't breaking anything anyone was relying on, because it shouldn't be breaking anything that consistently worked?

(Now we'll see if the tests pass. :P )

[cds-amal]

Note that the existing behavior for such imports was for them to be resolved relative to the directory the command was running in
wow

[cds-amal]

Wow @haltman-at. The old behavior is quite astonishing! I think we should have tests for this new behavior.

[haltman-at]

So you're saying there should be a test of compilation failure upon doing this? Well, I can try to find a place to add that...

[haltman-at]

OK I added the test, and also manually confirmed that the test fails without the fix.

[cds-amal]

Looks good @haltman-at!