Importing json/yaml crashes nls

[simonzkl]

Importing json/yaml crashes nls

[simonzkl]

After narrowing it down, I think just switching to yaml triggers this one. It's a different line than I wrote though. Mentioned it from memory, so it was incorrect.

import "test.yaml"

[2023-06-20T06:58:23Z TRACE nls::files] Parsed, checking types
[2023-06-20T06:58:23Z DEBUG nls::linearization] adding term: Null @ None
[2023-06-20T06:58:23Z DEBUG nls::linearization] linearizing
[2023-06-20T06:58:23Z DEBUG nls::linearization] unresolved references: []
[2023-06-20T06:58:23Z DEBUG nls::linearization] adding term: ResolvedImport(FileId(4)) @ Original(RawSpan { src_id: FileId(3), start: ByteIndex(1), end: ByteIndex(19) })
thread 'main' panicked at 'TermPos::unwrap', lsp/nls/src/linearization/mod.rs:471:38
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[Error - 08:58:23] Connection to server got closed. Server will not be restarted.

[simonzkl]

Anecdotally, I've also had it panic in a different location for the same reason:

nickel/lsp/nls/src/linearization/mod.rs

Lines 463 to 466 in 00b6ce9

	// This is safe because the import file is resolved, before we linearize
	// the containing file, therefore the cache MUST have the term stored.
	let term = lin.cache.get(*file).unwrap();
	let position = final_term_pos(&term);

[yannham]

@simonzkl I have a fix for my simple test case (and which makes sense with respect to the original location of the panic). But I didn't hit the second location yet. Maybe it's an artifact of the first issue, but just in case, would you mind sharing the JSON file you tried?

[yannham]

Ok, this is more in line with my own findings. Thanks!