oxalica / nil

NIx Language server, an incremental analysis assistant for writing in Nix.
Apache License 2.0
1.32k stars 39 forks source link

"failed to resolve flake inputs from lock file" since a recent update #56

Closed montchr closed 1 year ago

montchr commented 1 year ago

Since updating my nil flake input in the past week (maybe two weeks ago, but this past Monday seems more accurate), I've been encountering some errors relating to flake inputs in both Emacs and VS Code. Most recently, I updated earlier today since I saw some updates available (I'm excited about the CLI!), but the errors continue.

Full output from within VS Code:

2023-02-03T21:36:22.164211Z ERROR nil::server: Failed to load flake workspace: Failed to resolve flake inputs from lock file: Missing followed input "flake-parts_2"
thread 'Worker' panicked at 'no value set for FlakeGraphQuery(())', /private/tmp/nix-build-nil-unstable-2023-02-03.drv-0/cargo-vendor-dir/salsa-0.17.0-pre.2/src/input.rs:106:32
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: <salsa::input::InputStorage<Q> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
   3: <DB as ide::base::SourceDatabase>::flake_graph::__shim
   4: <ide::base::SourceRootFlakeInfoQuery as salsa::plumbing::QueryFunction>::execute
   5: salsa::runtime::Runtime::execute_query_implementation
   6: salsa::derived::slot::Slot<Q,MP>::read_upgrade
   7: salsa::derived::slot::Slot<Q,MP>::read
   8: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
   9: <DB as ide::base::SourceDatabase>::source_root_flake_info::__shim
  10: <ide::def::ModuleKindQuery as salsa::plumbing::QueryFunction>::execute
  11: salsa::runtime::Runtime::execute_query_implementation
  12: salsa::derived::slot::Slot<Q,MP>::read_upgrade
  13: salsa::derived::slot::Slot<Q,MP>::read
  14: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
  15: <DB as ide::def::DefDatabase>::module_kind::__shim
  16: <ide::ty::ModuleExpectedTyQuery as salsa::plumbing::QueryFunction>::execute
  17: salsa::runtime::Runtime::execute_query_implementation
  18: salsa::derived::slot::Slot<Q,MP>::read_upgrade
  19: salsa::derived::slot::Slot<Q,MP>::read
  20: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
  21: <DB as ide::ty::TyDatabase>::module_expected_ty::__shim
  22: ide::ty::infer::infer_query
  23: salsa::runtime::Runtime::execute_query_implementation
  24: salsa::derived::slot::Slot<Q,MP>::read_upgrade
  25: salsa::derived::slot::Slot<Q,MP>::read
  26: <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch
  27: <DB as ide::ty::TyDatabase>::infer::__shim
  28: ide::ide::completion::complete_attrpath
  29: ide::ide::completion::completions
  30: std::panicking::try
  31: ide::ide::Analysis::completions
  32: nil::handler::completion
  33: std::panicking::try
  34: core::ops::function::FnOnce::call_once{{vtable.shim}}
  35: nil::server::Server::worker
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

And a couple minutes later on textDocument/completion:

2023-02-03T21:38:34.702716Z ERROR nil::server: Panicked in textDocument/completion: no value set for FlakeGraphQuery(())
Location: /private/tmp/nix-build-nil-unstable-2023-02-03.drv-0/cargo-vendor-dir/salsa-0.17.0-pre.2/src/input.rs:106:32
Backtrace:    0:        0x1008610b0 - std::backtrace::Backtrace::create::h7400495e7025675b
   1:        0x1006635e0 - nil::server::with_catch_unwind::{{closure}}::{{closure}}::h0a93ffacf644c2f6
   2:        0x1008633f4 - std::panicking::rust_panic_with_hook::h9612ea60473690f5
   3:        0x10083fd00 - std::panicking::begin_panic_handler::{{closure}}::h0ed5ffb8fac8e5e4
   4:        0x10083f690 - std::sys_common::backtrace::__rust_end_short_backtrace::he27c5ac6e14ee346
   5:        0x100862f10 - _rust_begin_unwind
   6:        0x1008927c8 - core::panicking::panic_fmt::h8cb04629bcd07630
   7:        0x100780260 - <salsa::input::InputStorage<Q> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch::hbe73f976149ba85a
   8:        0x1007532ac - <DB as ide::base::SourceDatabase>::flake_graph::__shim::h148e05299fa58e8f
   9:        0x1007534e4 - <ide::base::SourceRootFlakeInfoQuery as salsa::plumbing::QueryFunction>::execute::ha4159f3da9800d9f
  10:        0x100745864 - salsa::runtime::Runtime::execute_query_implementation::h7880e39ac4e98315
  11:        0x10070a1bc - salsa::derived::slot::Slot<Q,MP>::read_upgrade::h5fe2284843cdb600
  12:        0x10071c514 - salsa::derived::slot::Slot<Q,MP>::read::h440eca51d6af3d3a
  13:        0x100768198 - <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch::h59d090648d630d62
  14:        0x100753100 - <DB as ide::base::SourceDatabase>::source_root_flake_info::__shim::hbd53f7ba3c281fea
  15:        0x100754cc0 - <ide::def::ModuleKindQuery as salsa::plumbing::QueryFunction>::execute::h1d59cebd97738cdc
  16:        0x100746ce4 - salsa::runtime::Runtime::execute_query_implementation::hff7c8ce98946fde7
  17:        0x100708430 - salsa::derived::slot::Slot<Q,MP>::read_upgrade::h2d6d5252b05f683a
  18:        0x10071f6e0 - salsa::derived::slot::Slot<Q,MP>::read::he9694427b180558f
  19:        0x10076ba4c - <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch::hb1acc1322b9b1a50
  20:        0x100753f04 - <DB as ide::def::DefDatabase>::module_kind::__shim::h9a6c90e2e63a6b9d
  21:        0x10079eb28 - <ide::ty::ModuleExpectedTyQuery as salsa::plumbing::QueryFunction>::execute::h37fb2615f4766950
  22:        0x100746758 - salsa::runtime::Runtime::execute_query_implementation::hc42ff644adf7038a
  23:        0x10070b08c - salsa::derived::slot::Slot<Q,MP>::read_upgrade::h640f2fc6e6f70e50
  24:        0x10071bfcc - salsa::derived::slot::Slot<Q,MP>::read::h258a54764295c323
  25:        0x100767940 - <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch::h4b034ac2e38ea201
  26:        0x10079e98c - <DB as ide::ty::TyDatabase>::module_expected_ty::__shim::ha2386ac4e4452e8d
  27:        0x10074fb94 - ide::ty::infer::infer_query::ha22aff44ab2f6d94
  28:        0x1007463ac - salsa::runtime::Runtime::execute_query_implementation::hb60c426a330bec80
  29:        0x10070fbd4 - salsa::derived::slot::Slot<Q,MP>::read_upgrade::hafa9e365ee614bfe
  30:        0x10071ca00 - salsa::derived::slot::Slot<Q,MP>::read::h7d42921af5192020
  31:        0x1007699e8 - <salsa::derived::DerivedStorage<Q,MP> as salsa::plumbing::QueryStorageOps<Q>>::try_fetch::h776c996a55a4e645
  32:        0x10079ea70 - <DB as ide::ty::TyDatabase>::infer::__shim::hf4c29333b3997d2a
  33:        0x100774d64 - ide::ide::completion::complete_attrpath::he17fa9c7b6b74b71
  34:        0x10077377c - ide::ide::completion::completions::h6d6466ada696a5c3
  35:        0x10073ecd0 - std::panicking::try::hf4e88a17daf14597
  36:        0x100781b64 - ide::ide::Analysis::completions::h837361770e9e96b4
  37:        0x100681680 - nil::handler::completion::h323f1a4f620ce675
  38:        0x1006663c8 - std::panicking::try::h9864bb468a06eff0
  39:        0x100655a44 - core::ops::function::FnOnce::call_once{{vtable.shim}}::h9a7b79f0ba9708f5
  40:        0x10065bc60 - nil::server::Server::worker::ha87214053ca331a7
  41:        0x100639370 - std::sys_common::backtrace::__rust_begin_short_backtrace::hd4064df7eec9f1ce
  42:        0x100667488 - core::ops::function::FnOnce::call_once{{vtable.shim}}::hbcbb9730d66bd906
  43:        0x10084dbdc - std::sys::unix::thread::Thread::new::thread_start::hca8cc49a6f4bf31a
  44:        0x198f9826c - __pthread_deallocate

At some point (in Emacs w/lsp-mode) I recall seeing a message advising me to run nix flake archive -- however that doesn't appear to fix the issues.

I'm also seeing similar errors on textDocument/definition and textDocument/hover requests. At a glance they seem likely to have the same root cause so I'll hold off on posting more error logs for now...

Aside from these issues (which I'm guessing are related to the recent improvements around flake inputs specifically), other functionality seems to be working as usual (e.g. flattening attrsets refactoring).

Edit: I'm running aarch64-darwin by the way.

Let me know if you need any more info. Thank you!

oxalica commented 1 year ago

The panic should be fixed now in 1a15174958729ca578db517e735479ed5fb963db.

For the flake loading issue, you can try to delete and recreate flake.lock. If the issue still exists, could you provide the content of flake.nix, flake.lock, and the output of nix flake archive --json?

teto commented 1 year ago

I dont have a panic but I see too: LSP[nil_ls] Failed to load flake workspace: Failed to resolve flake inputs from lock file: Missing followed input "nixpkgs_2"

I suspect nil tries to match a flake input to everything in the lockfile but if you dont use follows, you can easily have 3/4 different versions of "nixpkgs" in the lockfile. Could that be it ?

montchr commented 1 year ago

The panic should be fixed now in 1a15174.

Yes, thank you!

For the flake loading issue, you can try to delete and recreate flake.lock.

Done, but still getting the "failed to load flake workspace..." messages.

I suspect nil tries to match a flake input to everything in the lockfile but if you dont use follows, you can easily have 3/4 different versions of "nixpkgs" in the lockfile. Could that be it ?

@oxalica @teto Yeah, that seems likely related. I have a few of those un-followed inputs in my flake.lock (posted below). Usually that applies to nixpkgs but flake-utils is another frequent culprit resulting in a bunch of flake-utils_* inputs. But it looks like the output of nix flake archive --json doesn't contain any of that numerical input mapping stuff from flake.lock.

FWIW, after re-creating flake.lock from scratch, flake-utils_7 is the input reported as missing most consistently. As of https://github.com/montchr/dotfield/commit/d9fd62dbf2f6c4f3f8e61cf0b0f87123de720459 that maps to the flake-utils input in my flake.nix. For some reason I pinned another input to follow my flake's flake-utils -- after removing that, the flake-utils_7 error went away but now we're on to nixos-unstable_2 etc., so I didn't commit that change.

If the issue still exists, could you provide the content of flake.nix, flake.lock, and the output of nix flake archive --json?

Here's a gist containing all of those:

https://gist.github.com/montchr/7e1d2dfc333fa1a7982e1a0c1b896bba

flake.nix and flake.lock were copied from https://github.com/montchr/dotfield/commit/d9fd62dbf2f6c4f3f8e61cf0b0f87123de720459.

oxalica commented 1 year ago

I suspect nil tries to match a flake input to everything in the lockfile but if you dont use follows, you can easily have 3/4 different versions of "nixpkgs" in the lockfile. Could that be it ?

Okay the problem is I misinterpret the followed inputs in flake.lock. The value of nodes' inputs means the node identifier in nodes, not an input of root_node.

https://github.com/oxalica/nil/blob/1a15174958729ca578db517e735479ed5fb963db/crates/nix-interop/src/flake_lock.rs#L40

I'll fix it later today.

oxalica commented 1 year ago

Here's a gist containing all of those:

https://gist.github.com/montchr/7e1d2dfc333fa1a7982e1a0c1b896bba

flake.nix and flake.lock were copied from montchr/dotfield@d9fd62d.

I couldn't download github:kleinweb/infra which seems to be private. But without it, that flake.nix works fine for me after 015ecacf4301eda59c40ad152109bc8656d49d1e. Could you verify it?

montchr commented 1 year ago

Yes! All is good. Thank you.