Merge commit 'd8fe5e6c'

Conflicts:
	nixpkgs/pkgs/build-support/go/module.nix

4 files changed, 113 insertions, 65 deletions

diff --git a/nixpkgs/doc/stdenv/cross-compilation.chapter.md b/nixpkgs/doc/stdenv/cross-compilation.chapter.md
index e659e1803807..76c931ba047a 100644
--- a/nixpkgs/doc/stdenv/cross-compilation.chapter.md
+++ b/nixpkgs/doc/stdenv/cross-compilation.chapter.md
@@ -15,7 +15,9 @@ Nixpkgs follows the [conventions of GNU autoconf](https://gcc.gnu.org/onlinedocs
 In Nixpkgs, these three platforms are defined as attribute sets under the names `buildPlatform`, `hostPlatform`, and `targetPlatform`. They are always defined as attributes in the standard environment. That means one can access them like:
 
 ```nix
-{ stdenv, fooDep, barDep, ... }: ...stdenv.buildPlatform...
+{ stdenv, fooDep, barDep, ... }: {
+  # ...stdenv.buildPlatform...
+}
 ```
 
 `buildPlatform`
@@ -127,7 +129,9 @@ Some frequently encountered problems when packaging for cross-compilation should
 Many packages assume that an unprefixed binutils (`cc`/`ar`/`ld` etc.) is available, but Nix doesn't provide one. It only provides a prefixed one, just as it only does for all the other binutils programs. It may be necessary to patch the package to fix the build system to use a prefix. For instance, instead of `cc`, use `${stdenv.cc.targetPrefix}cc`.
 
 ```nix
-makeFlags = [ "CC=${stdenv.cc.targetPrefix}cc" ];
+{
+  makeFlags = [ "CC=${stdenv.cc.targetPrefix}cc" ];
+}
 ```
 
 #### How do I avoid compiling a GCC cross-compiler from source? {#cross-qa-avoid-compiling-gcc-cross-compiler}
@@ -142,7 +146,9 @@ $ nix-build '<nixpkgs>' -A pkgsCross.raspberryPi.hello
 Add the following to your `mkDerivation` invocation.
 
 ```nix
-depsBuildBuild = [ buildPackages.stdenv.cc ];
+{
+  depsBuildBuild = [ buildPackages.stdenv.cc ];
+}
 ```
 
 #### My package’s testsuite needs to run host platform code. {#cross-testsuite-runs-host-code}
@@ -150,7 +156,9 @@ depsBuildBuild = [ buildPackages.stdenv.cc ];
 Add the following to your `mkDerivation` invocation.
 
 ```nix
-doCheck = stdenv.buildPlatform.canExecute stdenv.hostPlatform;
+{
+  doCheck = stdenv.buildPlatform.canExecute stdenv.hostPlatform;
+}
 ```
 
 #### Package using Meson needs to run binaries for the host platform during build. {#cross-meson-runs-host-code}
@@ -159,12 +167,14 @@ Add `mesonEmulatorHook` to `nativeBuildInputs` conditionally on if the target bi
 
 e.g.
 
-```
-nativeBuildInputs = [
-  meson
-] ++ lib.optionals (!stdenv.buildPlatform.canExecute stdenv.hostPlatform) [
-  mesonEmulatorHook
-];
+```nix
+{
+  nativeBuildInputs = [
+    meson
+  ] ++ lib.optionals (!stdenv.buildPlatform.canExecute stdenv.hostPlatform) [
+    mesonEmulatorHook
+  ];
+}
 ```
 
 Example of an error which this fixes.
diff --git a/nixpkgs/doc/stdenv/meta.chapter.md b/nixpkgs/doc/stdenv/meta.chapter.md
index 4a3b04b8f6e4..7f57eda791ea 100644
--- a/nixpkgs/doc/stdenv/meta.chapter.md
+++ b/nixpkgs/doc/stdenv/meta.chapter.md
@@ -3,17 +3,19 @@
 Nix packages can declare *meta-attributes* that contain information about a package such as a description, its homepage, its license, and so on. For instance, the GNU Hello package has a `meta` declaration like this:
 
 ```nix
-meta = {
-  description = "A program that produces a familiar, friendly greeting";
-  longDescription = ''
-    GNU Hello is a program that prints "Hello, world!" when you run it.
-    It is fully customizable.
-  '';
-  homepage = "https://www.gnu.org/software/hello/manual/";
-  license = lib.licenses.gpl3Plus;
-  maintainers = with lib.maintainers; [ eelco ];
-  platforms = lib.platforms.all;
-};
+{
+  meta = {
+    description = "A program that produces a familiar, friendly greeting";
+    longDescription = ''
+      GNU Hello is a program that prints "Hello, world!" when you run it.
+      It is fully customizable.
+    '';
+    homepage = "https://www.gnu.org/software/hello/manual/";
+    license = lib.licenses.gpl3Plus;
+    maintainers = with lib.maintainers; [ eelco ];
+    platforms = lib.platforms.all;
+  };
+}
 ```
 
 Meta-attributes are not passed to the builder of the package. Thus, a change to a meta-attribute doesn’t trigger a recompilation of the package.
@@ -82,7 +84,9 @@ The *priority* of the package, used by `nix-env` to resolve file name conflicts
 The list of Nix platform types on which the package is supported. Hydra builds packages according to the platform specified. If no platform is specified, the package does not have prebuilt binaries. An example is:
 
 ```nix
-meta.platforms = lib.platforms.linux;
+{
+  meta.platforms = lib.platforms.linux;
+}
 ```
 
 Attribute Set `lib.platforms` defines [various common lists](https://github.com/NixOS/nixpkgs/blob/master/lib/systems/doubles.nix) of platforms types.
@@ -95,8 +99,10 @@ In general it is preferable to set `meta.platforms = lib.platforms.all` and then
 For example, a package which requires dynamic linking and cannot be linked statically could use this:
 
 ```nix
-meta.platforms = lib.platforms.all;
-meta.badPlatforms = [ lib.systems.inspect.patterns.isStatic ];
+{
+  meta.platforms = lib.platforms.all;
+  meta.badPlatforms = [ lib.systems.inspect.patterns.isStatic ];
+}
 ```
 
 The [`lib.meta.availableOn`](https://github.com/NixOS/nixpkgs/blob/b03ac42b0734da3e7be9bf8d94433a5195734b19/lib/meta.nix#L95-L106) function can be used to test whether or not a package is available (i.e. buildable) on a given platform.
@@ -136,7 +142,7 @@ For more on how to write and run package tests, see [](#sec-package-tests).
 The NixOS tests are available as `nixosTests` in parameters of derivations. For instance, the OpenSMTPD derivation includes lines similar to:
 
 ```nix
-{ /* ... */, nixosTests }:
+{ /* ... , */ nixosTests }:
 {
   # ...
   passthru.tests = {
@@ -194,8 +200,10 @@ To be effective, it must be presented directly to an evaluation process that han
 The list of Nix platform types for which the [Hydra](https://github.com/nixos/hydra) [instance at `hydra.nixos.org`](https://nixos.org/hydra) will build the package. (Hydra is the Nix-based continuous build system.) It defaults to the value of `meta.platforms`. Thus, the only reason to set `meta.hydraPlatforms` is if you want `hydra.nixos.org` to build the package on a subset of `meta.platforms`, or not at all, e.g.
 
 ```nix
-meta.platforms = lib.platforms.linux;
-meta.hydraPlatforms = [];
+{
+  meta.platforms = lib.platforms.linux;
+  meta.hydraPlatforms = [];
+}
 ```
 
 ### `broken` {#var-meta-broken}
@@ -209,13 +217,17 @@ This means that `broken` can be used to express constraints, for example:
 - Does not cross compile
 
   ```nix
-   meta.broken = !(stdenv.buildPlatform.canExecute stdenv.hostPlatform)
+  {
+    meta.broken = !(stdenv.buildPlatform.canExecute stdenv.hostPlatform);
+  }
   ```
 
 - Broken if all of a certain set of its dependencies are broken
 
   ```nix
-  meta.broken = lib.all (map (p: p.meta.broken) [ glibc musl ])
+  {
+    meta.broken = lib.all (map (p: p.meta.broken) [ glibc musl ]);
+  }
   ```
 
 This makes `broken` strictly more powerful than `meta.badPlatforms`.
diff --git a/nixpkgs/doc/stdenv/multiple-output.chapter.md b/nixpkgs/doc/stdenv/multiple-output.chapter.md
index 1ee063c0c2f4..5e86d2aa3d56 100644
--- a/nixpkgs/doc/stdenv/multiple-output.chapter.md
+++ b/nixpkgs/doc/stdenv/multiple-output.chapter.md
@@ -30,7 +30,9 @@ Here you find how to write a derivation that produces multiple outputs.
 In nixpkgs there is a framework supporting multiple-output derivations. It tries to cover most cases by default behavior. You can find the source separated in `<nixpkgs/pkgs/build-support/setup-hooks/multiple-outputs.sh>`; it’s relatively well-readable. The whole machinery is triggered by defining the `outputs` attribute to contain the list of desired output names (strings).
 
 ```nix
-outputs = [ "bin" "dev" "out" "doc" ];
+{
+  outputs = [ "bin" "dev" "out" "doc" ];
+}
 ```
 
 Often such a single line is enough. For each output an equally named environment variable is passed to the builder and contains the path in nix store for that output. Typically you also want to have the main `out` output, as it catches any files that didn’t get elsewhere.
diff --git a/nixpkgs/doc/stdenv/stdenv.chapter.md b/nixpkgs/doc/stdenv/stdenv.chapter.md
index a948c6757c4a..a1e27b7bdf7f 100644
--- a/nixpkgs/doc/stdenv/stdenv.chapter.md
+++ b/nixpkgs/doc/stdenv/stdenv.chapter.md
@@ -36,7 +36,7 @@ Many packages have dependencies that are not provided in the standard environmen
 stdenv.mkDerivation {
   pname = "libfoo";
   version = "1.2.3";
-  ...
+  # ...
   buildInputs = [libbar perl ncurses];
 }
 ```
@@ -49,7 +49,7 @@ Often it is necessary to override or modify some aspect of the build. To make th
 stdenv.mkDerivation {
   pname = "fnord";
   version = "4.5";
-  ...
+  # ...
   buildPhase = ''
     gcc foo.c -o foo
   '';
@@ -70,7 +70,7 @@ While the standard environment provides a generic builder, you can still supply
 stdenv.mkDerivation {
   pname = "libfoo";
   version = "1.2.3";
-  ...
+  # ...
   builder = ./builder.sh;
 }
 ```
@@ -449,11 +449,13 @@ Unless set to `false`, some build systems with good support for parallel buildin
 This is an attribute set which can be filled with arbitrary values. For example:
 
 ```nix
-passthru = {
-  foo = "bar";
-  baz = {
-    value1 = 4;
-    value2 = 5;
+{
+  passthru = {
+    foo = "bar";
+    baz = {
+      value1 = 4;
+      value2 = 5;
+    };
   };
 }
 ```
@@ -467,27 +469,33 @@ A script to be run by `maintainers/scripts/update.nix` when the package is match
 - []{#var-passthru-updateScript-command} an executable file, either on the file system:
 
   ```nix
-  passthru.updateScript = ./update.sh;
+  {
+    passthru.updateScript = ./update.sh;
+  }
   ```
 
   or inside the expression itself:
 
   ```nix
-  passthru.updateScript = writeScript "update-zoom-us" ''
-    #!/usr/bin/env nix-shell
-    #!nix-shell -i bash -p curl pcre2 common-updater-scripts
+  {
+    passthru.updateScript = writeScript "update-zoom-us" ''
+      #!/usr/bin/env nix-shell
+      #!nix-shell -i bash -p curl pcre2 common-updater-scripts
 
-    set -eu -o pipefail
+      set -eu -o pipefail
 
-    version="$(curl -sI https://zoom.us/client/latest/zoom_x86_64.tar.xz | grep -Fi 'Location:' | pcre2grep -o1 '/(([0-9]\.?)+)/')"
-    update-source-version zoom-us "$version"
-  '';
+      version="$(curl -sI https://zoom.us/client/latest/zoom_x86_64.tar.xz | grep -Fi 'Location:' | pcre2grep -o1 '/(([0-9]\.?)+)/')"
+      update-source-version zoom-us "$version"
+    '';
+  }
   ```
 
 - a list, a script followed by arguments to be passed to it:
 
   ```nix
-  passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ];
+  {
+    passthru.updateScript = [ ../../update.sh pname "--requested-release=unstable" ];
+  }
   ```
 
 - an attribute set containing:
@@ -496,18 +504,22 @@ A script to be run by `maintainers/scripts/update.nix` when the package is match
   - [`supportedFeatures`]{#var-passthru-updateScript-set-supportedFeatures} (optional) – a list of the [extra features](#var-passthru-updateScript-supported-features) the script supports.
 
   ```nix
-  passthru.updateScript = {
-    command = [ ../../update.sh pname ];
-    attrPath = pname;
-    supportedFeatures = [ … ];
-  };
+  {
+    passthru.updateScript = {
+      command = [ ../../update.sh pname ];
+      attrPath = pname;
+      supportedFeatures = [ /* ... */ ];
+    };
+  }
   ```
 
 ::: {.tip}
 A common pattern is to use the [`nix-update-script`](https://github.com/NixOS/nixpkgs/blob/master/pkgs/common-updater/nix-update.nix) attribute provided in Nixpkgs, which runs [`nix-update`](https://github.com/Mic92/nix-update):
 
 ```nix
-passthru.updateScript = nix-update-script { };
+{
+  passthru.updateScript = nix-update-script { };
+}
 ```
 
 For simple packages, this is often enough, and will ensure that the package is updated automatically by [`nixpkgs-update`](https://ryantm.github.io/nixpkgs-update) when a new version is released. The [update bot](https://nix-community.org/update-bot) runs periodically to attempt to automatically update packages, and will run `passthru.updateScript` if set. While not strictly necessary if the project is listed on [Repology](https://repology.org), using `nix-update-script` allows the package to update via many more sources (e.g. GitHub releases).
@@ -846,7 +858,9 @@ The file name of the Makefile.
 A list of strings passed as additional flags to `make`. These flags are also used by the default install and check phase. For setting make flags specific to the build phase, use `buildFlags` (see below).
 
 ```nix
-makeFlags = [ "PREFIX=$(out)" ];
+{
+  makeFlags = [ "PREFIX=$(out)" ];
+}
 ```
 
 ::: {.note}
@@ -858,9 +872,11 @@ The flags are quoted in bash, but environment variables can be specified by usin
 A shell array containing additional arguments passed to `make`. You must use this instead of `makeFlags` if the arguments contain spaces, e.g.
 
 ```nix
-preBuild = ''
-  makeFlagsArray+=(CFLAGS="-O0 -g" LDFLAGS="-lfoo -lbar")
-'';
+{
+  preBuild = ''
+    makeFlagsArray+=(CFLAGS="-O0 -g" LDFLAGS="-lfoo -lbar")
+  '';
+}
 ```
 
 Note that shell arrays cannot be passed through environment variables, so you cannot set `makeFlagsArray` in a derivation attribute (because those are passed through environment variables): you have to define them in shell code.
@@ -892,7 +908,9 @@ The check phase checks whether the package was built correctly by running its te
 Controls whether the check phase is executed. By default it is skipped, but if `doCheck` is set to true, the check phase is usually executed. Thus you should set
 
 ```nix
-doCheck = true;
+{
+  doCheck = true;
+}
 ```
 
 in the derivation to enable checks. The exception is cross compilation. Cross compiled builds never run tests, no matter how `doCheck` is set, as the newly-built program won’t run on the platform used to build it.
@@ -945,7 +963,9 @@ See the [build phase](#var-stdenv-makeFlags) for details.
 The make targets that perform the installation. Defaults to `install`. Example:
 
 ```nix
-installTargets = "install-bin install-doc";
+{
+  installTargets = "install-bin install-doc";
+}
 ```
 
 ##### `installFlags` / `installFlagsArray` {#var-stdenv-installFlags}
@@ -1024,7 +1044,7 @@ This example prevents all `*.rlib` files from being stripped:
 ```nix
 stdenv.mkDerivation {
   # ...
-  stripExclude = [ "*.rlib" ]
+  stripExclude = [ "*.rlib" ];
 }
 ```
 
@@ -1033,7 +1053,7 @@ This example prevents files within certain paths from being stripped:
 ```nix
 stdenv.mkDerivation {
   # ...
-  stripExclude = [ "lib/modules/*/build/* ]
+  stripExclude = [ "lib/modules/*/build/*" ];
 }
 ```
 
@@ -1134,7 +1154,9 @@ It is often better to add tests that are not part of the source distribution to
 Controls whether the installCheck phase is executed. By default it is skipped, but if `doInstallCheck` is set to true, the installCheck phase is usually executed. Thus you should set
 
 ```nix
-doInstallCheck = true;
+{
+  doInstallCheck = true;
+}
 ```
 
 in the derivation to enable install checks. The exception is cross compilation. Cross compiled builds never run tests, no matter how `doInstallCheck` is set, as the newly-built program won’t run on the platform used to build it.
@@ -1244,9 +1266,11 @@ To use this, add `removeReferencesTo` to `nativeBuildInputs`.
 As `remove-references-to` is an actual executable and not a shell function, it can be used with `find`.
 Example removing all references to the compiler in the output:
 ```nix
-postInstall = ''
-  find "$out" -type f -exec remove-references-to -t ${stdenv.cc} '{}' +
-'';
+{
+  postInstall = ''
+    find "$out" -type f -exec remove-references-to -t ${stdenv.cc} '{}' +
+  '';
+}
 ```
 
 ### `substitute` \<infile\> \<outfile\> \<subs\> {#fun-substitute}