Fix/deprecate freeform type bad type

[roberth]

• An alternative to lib/types: fix either lazy value regression in case of non-matching v… #438558

I believe this provides a clearer fix with fewer workarounds.

We may further simplify this by removing the first commit, which is a very niche corner case that might not even help anyone.

TODO

• tests

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

---

Add a 👍 reaction to pull requests you find important.

[hsjobeki]

Suggested change

	"deprecation warning: while accessing option ${showOption loc}: (t.merge.v2 defs).value must only be accessed when `.headError == null`. This is a bug in code that consumes a module system type."
	"deprecation warning: while accessing option ${showOption loc}: (t.merge.v2 defs).value must only be accessed when `.headError == null`. This means the type is incorrect and will throw an error on the next release."

Or something like this. "a bug in code that consumes a module system type" isn't really actionable.
As a user i would like to know that i need to fix my type. This gives the impression that there is nothing to be done from a users side.

[roberth]

This is a niche warning that only triggers if users call it in other circumstances than freeformType.
The other message gets triggered for that.
See my commit messages.

[hsjobeki]

I'm not sure if we should print non-actionable error/warning messages

Please read my comment and/or commit messages

[hsjobeki]

I think i am in favor of this solution rather than #438558. The risk of changing merge further is currently to big, and feels a bit rushed, while this is the correct solution. Use mergeDefinitions fixing the merge behavior of freeform.

But also changing the freeform merge has the risk to reveal other regressions. That relied on freeform beeing unchecked.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/breaking-changes-announcement-for-unstable/17574/97

[hsjobeki]

I think i am a bit afraid of this PR could change the semantics of freeformType

Maybe we should reconsider a two step solution? enabling check for freeformType could introduce more hidden regressions.
These bad usages of freeformType are all over nixpkgs.

Step 1 could be to just remove the abort in the magical either case for now.
Its less invasive to the merge behavior of freeformTypes