Wrong unused binding

[viperML]

{
  hello,
  symlinkJoin,
  lib,
} @ inputs:
symlinkJoin {
  name = "foo";
  paths = builtins.filter lib.isDerivation (builtins.attrValues inputs);
}

nil reports an unused_binding on hello, while it is not the case.

[NobbZ]

hello is unused. The fact that inputs.hello does not exist without the explicit hello in the argset due to being callPackageed doesn't change that.

[viperML]

You can evaluate this expression without callPackage or builtins.functionArgs with import ./test.nix (with import <nixpkgs> {}; {inherit hello symlinkJoin lib;})

[NobbZ]

Either way hello is not used, and you'd need ... to signify "and others", you then can not use callPackage anymore.

Point remains, hello is unused currently and nil is rightfully complaining.

[inclyc]

The problem here is: {a, unused }@arg: a, the formal[^formal] unused might be used later by accessing arg, but the language server cannot precisely track it.

In libnixf we treat { a, unused }@arg: a differently from { a, unused }: a

See the image below:

Case 1: maybeReferenced could be referenced later from c, thus this is a "Hint". It causes the editor rendering faded text. Case 2: b is definitely unused, thus this is a "Warning". Hinting the user to fix that.

Either way hello is not used, and you'd need ... to signify "and others", you then can not use callPackage anymore.

That's the reason why hello is used in this case. Unused things are something we can safely remove without further modifications. If it affects the usage of callPackage, then hello is actually used (but yes, it is not "directly used", by its name).

[^formal]: In Nix language parser (official) it is called "formal", but not very documented.

[viperML]

I do agree that this might be or not an issue depending on how we define "using"...

[NobbZ]

In {bar}@foo: foo.bar, the binding bar is unused. The value of it is not unused.

I do see, that the use of the unused binding in the pattern slightly improves the error message in case of calling the function wrong, I also see the benefits in using Vipers original example and how it enables the usage of callPackage where it wouldn't be possible otherwise.

Still, I consider the warning "unused binding" correct, as the binding itself remains unused.

I would prefer an explicit "#ignore: unused" magic comment or so, rather than implicit logic in nil (or the supporting library) that would heuristically decide whether or not a bindings value was used by the use of the encapsulating attribute set.

---

I do agree that this might be or not an issue depending on how we define "using"...

As seen above, its not about how we define "unused", it is about the object it describes.