Motivation for this change

Submodules receive the name argument which tells them which attribute they are defined under. E.g.

{ lib, ... }: {
  options.foo = lib.mkOption {
    type = lib.types.attrsOf (lib.types.submodule ({ name, ... }: {
      options.name = lib.mkOption { default = name; };
    }));
  };
  config.foo.bar = {};
}

This makes the foo option evaluate to { bar = { name = "bar"; }; }

However there are also some problems with this, namely (hah):

1. If the submodule isn't defined under an attrsOf, the name isn't relevant at all. E.g.

   { lib, ... }: {
     options.foo = lib.mkOption {
       type = lib.types.submodule ({ name, ... }: {
         options.name = lib.mkOption { default = name; };
       });
     };
     config.foo = {};
   }

   makes the foo option evaluate to { name = "foo"; }. This isn't useful at all since the name is just the option name, which you can already know without this.

2. If the submodule is defined under multiple attrsOf, the name only tells you about the latest one. E.g.

   { lib, ... }: {
     options.foo = lib.mkOption {
       type = lib.types.attrsOf (lib.types.attrsOf (lib.types.submodule ({ name, ... }: {
         options.name = lib.mkOption { default = name; };
       })));
     };
     config.foo.bar.baz = {};
   }

   makes the foo option evaluate to { bar = { baz = { name = "baz"; }; }; }. You can see that the submodule doesn't get the information that it's under the bar attribute.

This changes fixes both of these problems by:

• Pointing name to the last relevant attribute the submodule is defined under, if any. For problem 1 this means that you now get an error that the name argument isn't passed. Or if the submodule was defined in a deeper attribute set, it would return the attribute name of it, instead of the option name. This is backwards incompatible for submodules that relied on the option name it's defined under to change its behavior, but I think that's fine, because that isn't the intended use of name.
• Exposing all attributes a submodule is defined under via the names argument, which contains them in reverse order. For problem 2 this means that names gives you [ "baz" "bar" ]. This is in reverse such that a static list index can be used to access elements, since the list can be arbitrarily long depending on where the submodule is evaluated.

Ping @roberth

@rycee You'll be able to remove this workaround with this change: https://github.com/nix-community/home-manager/blob/249650a07ee2d949fa599f3177a8c234adbd1bee/modules/lib/types-dag.nix#L24-L28

Things done

• Added a test