This is guaranteed to be safe. The tree can be a simple string if the
fileset is the same as the root, but the `or` takes care of that. In the
`or` case, the tree is guaranteed to fail the isAttrs check, and so even
though the index is invalid, it won't matter.
The stringLength check is equivalent at this point, but having to
actualy create the thunk for calling stringLength is likely slower than
just letting Nix handle the equality check.
The source filter runs on every path underneath the base directory, but
only on the few paths above it.
Reorder the prefix checks so the dominant below-the-base case does a
single substring + comparison instead of two, with an explicit branch
for the path being the base itself (which the previous first check also covered).
_normaliseTreeFilter strictly walks the entire file set tree on every
toSource call. File entries (null or a file type string) are already
normalised, so dispatch on the subtree inside the mapAttrs closure
instead of making a recursive call that immediately returns its
argument. This also avoids allocating an unused `path + "/${name}"`
argument thunk for every file.
This function runs once per directory node per union during lazy tree evaluation.
This makes it one of the hottest paths in lib.fileset for large trees.
It was measuared at ~9% of _total evaluation_ time in a very large monorepo.
This change is a 2-in-1:
- Return singleton lists directly to avoid rebuilding subtrees
- Use foldl instead of findFirstIndex
This is a hot path so the indexing arithmetic adds up.
- concrete types start with uppercase: Int, String, Bool, Derivation,
etc.
- type variables start with lowercase: a, b, etc.
- list:
- use `[x]` for homogeneous lists instead of `List x` or `[ x ]`
- use `List` for heterogeneous lists (not that common in `lib`)
- attr:
- use `AttrSet` for a generic attribute set type
- use `{ key1 :: Type1; key2 :: Type2; ... }` for adding signatures
for known attribute names and types
- use `{ key1 = value1; key2 = value2; ... }` for adding attributes
with known literals
- end with an ellipsis (`...`) if the set can contain unknown
attributes
- use `{ [String] :: x }` if all the attributes has the same type `x`
- prefer `Any` over `a` if the latter is not reused
After final improvements to the official formatter implementation,
this commit now performs the first treewide reformat of Nix files using it.
This is part of the implementation of RFC 166.
Only "inactive" files are reformatted, meaning only files that
aren't being touched by any PR with activity in the past 2 months.
This is to avoid conflicts for PRs that might soon be merged.
Later we can do a full treewide reformat to get the rest,
which should not cause as many conflicts.
A CI check has already been running for some time to ensure that new and
already-formatted files are formatted, so the files being reformatted here
should also stay formatted.
This commit was automatically created and can be verified using
nix-build a08b3a4d19.tar.gz \
--argstr baseRev b32a094368
result/bin/apply-formatting $NIXPKGS_PATH
This was found when trying to run the fileset tests on Darwin
(https://github.com/NixOS/nix/pull/9546#issuecomment-1967409445), which mysteriously fail on Darwin:
test case at lib/fileset/tests.sh:342 failed: toSource { root = "/nix/store/foobar"; fileset = ./.; } should have errored with this regex pattern:
lib.fileset.toSource: `root` \(/nix/store/foobar\) is a string-like value, but it should be a path instead.
\s*Paths in strings are not supported by `lib.fileset`, use `lib.sources` or derivations instead.
but this was the actual error:
error: lib.fileset.toSource: `root` (/nix/store/foobar) is a string-like value, but it should be a path instead.
Paths in strings are not supported by `lib.fileset`, use `lib.sources` or derivations instead.
After dissecting this, I find out that apparently \s works on Linux, but not on Darwin for some reason!
From the bash source code, it looks like <regex.h> with `REG_EXTENDED` is used for all platforms the same,
so there's nothing odd there.
It's almost impossible to know where <regex.h> comes from,
but it looks to be a POSIX thing.
So after digging through the almost impossible to find POSIX specifications
(https://pubs.opengroup.org/onlinepubs/007908799/xbd/re.html#tag_007_003_005),
I can indeed confirm that there's no mention of \s or the like!
_However_, there is a mention of `[[:blank:]]`, so we'll use that instead.
The only reason shallow clones are not the default in
`builtins.fetchGit` is that `revCount` can't be provided when cloning a
shallow repository. However, `revCount` isn't used or exposed by
`lib.fileset`. Hence, allowing cloning shallow repositories makes
`gitTracked` more general without any drawbacks.
Co-authored-by: Silvan Mosberger <github@infinisil.com>
- Make fromSource's missing file error message more consistent with others,
and add a test for it
- Indent some function arguments
- Fix an internal type
While this change is backwards-incompatible, I think it's okay because:
- The `fileFilter` function is not yet in a stable NixOS release, it was only merged about [a month ago](https://github.com/NixOS/nixpkgs/pull/257356).
- All public uses of the function on GitHub only pass a path
- Any `fileFilter pred fileset` can also be expressed as `intersection fileset (fileFilter pred path)` without loss of functionality.
- This is furthermore pointed out in the new error message when a file set is passed