Remove uses of pathtype library.

[patrickt]

pathtype was not a great success for us:

• it did not catch any bugs other than exposing some odd behavior in readProjectFromPaths;
• it baffled everyone who hadn't spent hours staring into its API (that is to say, me)
• it used error to check string literals, which is... fine, I guess, but doesn't help much in actuality;
• it complicated error reporting and assemblage;
• completely switching away from FilePath was not an option, as libraries like directory-tree and Glob require it;
• its documentation is very poor and difficult to navigate.

Furthermore, pathtype doesn't solve the most fundamental problem with the
FilePath type currently in base: its String representation. The only valid
representation for cross-platform file paths is ByteString, because Windows
paths can contain unpaired UTF-16 surrogates. Upcoming revisions of the library
are switching it to a ShortByteString representation, which is the Right Thing.

I think the lesson learned here is that "parse, don't validate" is not super
practical when the entire world has built around validation of file paths rather
than parsing them. Indeed, true validation of file paths would entail IO
everywhere, as we'd want to check for the existence and validity of a file path.

[robrix]

I'm in favour modulo CI (obvs) 👍🏻

[robrix]

1094

< {"files":[{"path":"semantic/test/fixtures/ruby/corpus/method-declaration.A.rb","language":"Ruby","symbols":[{"symbol":"foo","kind":"Method","line":"def foo","span":{"start":{"line":1,"column":5},"end":{"line":1,"column":8}},"nodeType":"DEFINITION","syntaxType":"METHOD","utf16CodeUnitSpan":{"start":{"column":4},"end":{"column":7}},"byteRange":{"start":4,"end":7}}]}]}

vs.

1096

> {"files":[{"path":"semantic/test/fixtures/ruby/corpus/and-or.A.rb","language":"Ruby","symbols":[{"symbol":"foo","kind":"Call","line":"foo and bar","span":{"start":{"line":1,"column":1},"end":{"line":1,"column":4}},"nodeType":"REFERENCE","syntaxType":"CALL","utf16CodeUnitSpan":{"start":{},"end":{"column":3}},"byteRange":{"end":3}},{"symbol":"bar","kind":"Call","line":"foo and bar","span":{"start":{"line":1,"column":9},"end":{"line":1,"column":12}},"nodeType":"REFERENCE","syntaxType":"CALL","utf16CodeUnitSpan":{"start":{"column":8},"end":{"column":11}},"byteRange":{"start":8,"end":11}}]}]}

welp

@patrickt: I have no explanation for this. I don't think I broke it with my merge conflict fix, but I can't rule it out. Thoughts?

(note that while these use the ruby fixtures, they are actually semantic's tests, and not semantic-ruby's)

[robrix]

Running the pre-merge commit locally with 8.10.7, I don't see that error, but I do see 31 errors due to uncaught NoSuchFile exceptions.

[robrix]

Same 31 failures with the master-merged commit with 9.2.1.

[patrickt]

@robrix Yeah I have absolutely no idea what this could be. Do we need to regenerate the fixtures or something?

[patrickt]

And why is it comparing one method-declaration test and one and-or test? That doesn’t seem right. Is there some ordering nonsense being thrown in here?

[robrix]

Let's see how far we get fixing the NoSuchFile exceptions; maybe that error was spurious?