aboutsummaryrefslogtreecommitdiff
path: root/src/libexpr/eval-cache.hh
AgeCommit message (Collapse)Author
2022-04-26nix: Respect meta.outputsToInstall, and use all outputs by defaultEelco Dolstra
'nix profile install' will now install all outputs listed in the package's meta.outputsToInstall attribute, or all outputs if that attribute doesn't exist. This makes it behave consistently with nix-env. Fixes #6385. Furthermore, for consistency, all other 'nix' commands do this as well. E.g. 'nix build' will build and symlink the outputs in meta.outputsToInstall, defaulting to all outputs. Previously, it only built/symlinked the first output. Note that this means that selecting a specific output using attrpath selection (e.g. 'nix build nixpkgs#libxml2.dev') no longer works. A subsequent PR will add a way to specify the desired outputs explicitly.
2022-04-26EvalCache AttrKey: Use Symbol instead of std::stringEelco Dolstra
2022-04-26EvalCache: Revert to using symbols in getAttr()Eelco Dolstra
2022-04-25rename SymbolIdx -> Symbol, Symbol -> SymbolStrpennae
after #6218 `Symbol` no longer confers a uniqueness invariant on the string it wraps, it is now possible to create multiple symbols that compare equal but whose string contents have different addresses. this guarantee is now only provided by `SymbolIdx`, leaving `Symbol` only as a string wrapper that knows about the intricacies of how symbols need to be formatted for output. this change renames `SymbolIdx` to `Symbol` to restore the previous semantics of `Symbol` to that name. we also keep the wrapper type and rename it to `SymbolStr` instead of returning plain strings from lookups into the symbol table because symbols are formatted for output in many places. theoretically we do not need `SymbolStr`, only a function that formats a string for output as a symbol, but having to wrap every symbol that appears in a message into eg `formatSymbol()` is error-prone and inconvient.
2022-04-21store Symbols in a table as well, like positionspennae
this slightly increases the amount of memory used for any given symbol, but this increase is more than made up for if the symbol is referenced more than once in the EvalState that holds it. on average every symbol should be referenced at least twice (once to introduce a binding, once to use it), so we expect no increase in memory on average. symbol tables are limited to 2³² entries like position tables, and similar arguments apply to why overflow is not likely: 2³² symbols would require as many string instances (at 24 bytes each) and map entries (at 24 bytes or more each, assuming that the map holds on average at most one item per bucket as the docs say). a full symbol table would require at least 192GB of memory just for symbols, which is well out of reach. (an ofborg eval of nixpks today creates less than a million symbols!)
2022-04-14Make InstallableFlake::toValue() and toDerivation() behave consistentlyEelco Dolstra
In particular, this means that 'nix eval` (which uses toValue()) no longer auto-calls functions or functors (because AttrCursor::findAlongAttrPath() doesn't). Fixes #6152. Also use ref<> in a few places, and don't return attrpaths from getCursor() because cursors already have a getAttrPath() method.
2022-03-11Create some type aliases for string ContextsJohn Ericson
2022-03-07Merge `or-suggestions.hh` into `suggestions.hh`regnat
No real need for keeping a separate header for such a simple class. This requires changing a bit `OrSuggestions<T>::operator*` to not throw an `Error` to prevent a cyclic dependency. But since this error is only thrown on programmer error, we can replace the whole method by a direct call to `std::get` which will raise its own assertion if needs be.
2022-03-07Move OrSuggestions to its own headerregnat
Prevents a recursive inclusion
2022-03-07Also display suggestions for the commands using the eval cacheregnat
Make `nix build .#nix-armv8l-linux` work for example
2021-04-19libcmd/installables: force re-evaluation of cached failuresMaximilian Bosch
I think that it's not very helpful to get "cached failures" in a wrong `flake.nix`. This can be very confusing when debugging a Nix expression. See for instance NixOS/nixpkgs#118115. In fact, the eval cache allows a forced reevaluation which is used for e.g. `nix eval`. This change makes sure that this is the case for `nix build` as well. So rather than λ ma27 [~/Projects/exp] → ../nix/outputs/out/bin/nix build -L --rebuild --experimental-features 'nix-command flakes' error: cached failure of attribute 'defaultPackage.x86_64-linux' the evaluation of already-evaluated (and failed) attributes looks like this now: λ ma27 [~/Projects/exp] → ../nix/outputs/out/bin/nix build -L --rebuild --experimental-features 'nix-command flakes' error: attribute 'hell' missing at /nix/store/mrnvi9ss8zn5wj6gpn4bcd68vbh42mfh-source/flake.nix:6:35: 5| 6| packages.x86_64-linux.hello = nixpkgs.legacyPackages.x86_64-linux.hell; | ^ 7| (use '--show-trace' to show detailed location information)
2020-10-06Shut up some clang warningsEelco Dolstra
2020-08-07nix build (and others): Force re-evaluation of cached errorsEelco Dolstra
Fixes #3872. This is a bit hacky. Ideally we would automatically re-evaluate the failed attribute iff we need to print the error message (so in commands like 'nix search' we wouldn't re-evaluate because we're suppressing errors).
2020-07-16Merge remote-tracking branch 'upstream/master' into hash-always-has-typeJohn Ericson
2020-06-29EvalCache: Store string contextsEelco Dolstra
2020-06-29Factor out EvalCache::forceDerivation()Eelco Dolstra
2020-04-27nix search: Search legacyPackages recursivelyEelco Dolstra
2020-04-20Move eval-cache.{cc,hh}Eelco Dolstra