DocumentRegistry bucket key contains `[object Object]`

[amcasey]

As of 93c3a30

getKeyForCompilationSetting joins compiler options as strings to form the key, but paths is an array. There may be other non-primitive settings values.

Example value: "1|99|true|1|true||2|c:/project|[object Object]||||true||||true||"

[amcasey]

Note that this means that we won't catch differences between path mappings and will inappropriately reuse SourceFiles.

[weswigham]

This issue has been a wild ride. The fix is obvious and simple - serialize the paths option into the key; easy enough. The problem comes when you try to write a failing test. To spoil the ending: it's hard. That this cache key doesn't actually include the paths option doesn't usually matter. Now, the reason for that is because of two other issues, both to do with /// <reference types directives (and one extending to all module resolutions as a whole).

So, let's start from the beginning. To make an example that fails because of this cache key requires us to reuse a source file between LS program builds with incorrect data cached onto a SourceFile, derived from the paths compiler option. There are fields that are exactly that, the resolvedTypeReferenceDirectiveNames member, which includes the path a type reference directive resolves to, and the resolvedModules field, which includes the resolution locations for normal imports. So you'd think, "oh, great! just change what an import or ///<reference types points to and we should see the old resolution result leak into the new program!" Sadly, not so! As it happens, even when we reuse source files from old programs, we reassign all of the resolved resolution members! We redo all the resolution work, unconditionally. It's unclear if this is strictly a bug - if a file we load already has resolved resolutions, we should probably be reusing them rather than redoing them; this alone prevents us from actually writing a test that fails because of this incomplete cache key. This means it's possible that this cache key issue could induce conflicts in a source file shared between two LS projects with different paths settings (rather than a single project that changes over time) because the second's program build will overwrite the resolutions done in the first, but writing a multi-project test is kind of annoying (maybe fourslash can be coaxed into it, but it'd be awkward).

Fixing that allows imports to actually exhibit bad behavior because of this cache key, but isn't quite enough for ///<reference types. Why's that? As it turns out, ///<reference types doesn't do any lookups via the paths compiler option. So that's another issue.

I'm probably going to put up a separate PR for the later issue, while the former will probably get fixed alongside this.