aboutsummaryrefslogtreecommitdiff
path: root/src/libexpr
AgeCommit message (Collapse)Author
2024-09-01repl-overlays: Provide an elaborate exampleRebecca Turner
This is the repl overlay from my dotfiles, which I think provides a reasonable and ergonomic set of variables. We can iterate on this over time, or (perhaps?) provide a sentinel value like `repl-overlays = <DEFAULT>` to include a "suggested default" overlay like this one. Change-Id: I8eba3934c50fbac8367111103e66c7375b8d134e
2024-08-28tree-wide: shuffle headers around for about 30s compile timeJade Lovelace
This didn't really feel so worth it afterwards, but I did untangle a bunch of stuff that should not have been tangled. The general gist of this change is that variant bullshit was causing a bunch of compile time, and it seems like the only way to deal with variant induced compile time is to keep variant types out of headers. Explicit template instantiation seems to do nothing for them. I also seem to have gotten some back-end time improvement from explicitly instantiating regex, but I don't know why. There is no corresponding front-end time improvement from it: regex is still at the top of the sinners list. **** Templates that took longest to instantiate: 15231 ms: std::basic_regex<char>::_M_compile (28 times, avg 543 ms) 15066 ms: std::__detail::_Compiler<std::regex_traits<char>>::_Compiler (28 times, avg 538 ms) 12571 ms: std::__detail::_Compiler<std::regex_traits<char>>::_M_disjunction (28 times, avg 448 ms) 12454 ms: std::__detail::_Compiler<std::regex_traits<char>>::_M_alternative (28 times, avg 444 ms) 12225 ms: std::__detail::_Compiler<std::regex_traits<char>>::_M_term (28 times, avg 436 ms) 11363 ms: nlohmann::basic_json<>::parse<const char *> (21 times, avg 541 ms) 10628 ms: nlohmann::basic_json<>::basic_json (109 times, avg 97 ms) 10134 ms: std::__detail::_Compiler<std::regex_traits<char>>::_M_atom (28 times, avg 361 ms) Back-end time before messing with the regex: **** Function sets that took longest to compile / optimize: 8076 ms: void boost::io::detail::put<$>(boost::io::detail::put_holder<$> cons... (177 times, avg 45 ms) 4382 ms: std::_Rb_tree<$>::_M_erase(std::_Rb_tree_node<$>*) (1247 times, avg 3 ms) 3137 ms: boost::stacktrace::detail::to_string_impl_base<boost::stacktrace::de... (137 times, avg 22 ms) 2896 ms: void boost::io::detail::mk_str<$>(std::__cxx11::basic_string<$>&, ch... (177 times, avg 16 ms) 2304 ms: std::_Rb_tree<$>::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_... (210 times, avg 10 ms) 2116 ms: bool std::__detail::_Compiler<$>::_M_expression_term<$>(std::__detai... (112 times, avg 18 ms) 2051 ms: std::_Rb_tree_iterator<$> std::_Rb_tree<$>::_M_emplace_hint_unique<$... (244 times, avg 8 ms) 2037 ms: toml::result<$> toml::detail::sequence<$>::invoke<$>(toml::detail::l... (93 times, avg 21 ms) 1928 ms: std::__detail::_Compiler<$>::_M_quantifier() (28 times, avg 68 ms) 1859 ms: nlohmann::json_abi_v3_11_3::detail::serializer<$>::dump(nlohmann::js... (41 times, avg 45 ms) 1824 ms: std::_Function_handler<$>::_M_manager(std::_Any_data&, std::_Any_dat... (973 times, avg 1 ms) 1810 ms: std::__detail::_BracketMatcher<$>::_BracketMatcher(std::__detail::_B... (112 times, avg 16 ms) 1793 ms: nix::fetchers::GitInputScheme::fetch(nix::ref<$>, nix::fetchers::Inp... (1 times, avg 1793 ms) 1759 ms: std::_Rb_tree<$>::_M_get_insert_unique_pos(std::__cxx11::basic_strin... (281 times, avg 6 ms) 1722 ms: bool nlohmann::json_abi_v3_11_3::detail::parser<$>::sax_parse_intern... (19 times, avg 90 ms) 1677 ms: boost::io::basic_altstringbuf<$>::overflow(int) (194 times, avg 8 ms) 1674 ms: std::__cxx11::basic_string<$>::_M_mutate(unsigned long, unsigned lon... (249 times, avg 6 ms) 1660 ms: std::_Rb_tree_node<$>* std::_Rb_tree<$>::_M_copy<$>(std::_Rb_tree_no... (304 times, avg 5 ms) 1599 ms: bool nlohmann::json_abi_v3_11_3::detail::parser<$>::sax_parse_intern... (19 times, avg 84 ms) 1568 ms: void std::__detail::_Compiler<$>::_M_insert_bracket_matcher<$>(bool) (112 times, avg 14 ms) 1541 ms: std::__shared_ptr<$>::~__shared_ptr() (531 times, avg 2 ms) 1539 ms: nlohmann::json_abi_v3_11_3::detail::serializer<$>::dump_escaped(std:... (41 times, avg 37 ms) 1471 ms: void std::__detail::_Compiler<$>::_M_insert_character_class_matcher<... (112 times, avg 13 ms) After messing with the regex (notice std::__detail::_Compiler vanishes here, but I don't know why): **** Function sets that took longest to compile / optimize: 8054 ms: void boost::io::detail::put<$>(boost::io::detail::put_holder<$> cons... (177 times, avg 45 ms) 4313 ms: std::_Rb_tree<$>::_M_erase(std::_Rb_tree_node<$>*) (1217 times, avg 3 ms) 3259 ms: boost::stacktrace::detail::to_string_impl_base<boost::stacktrace::de... (137 times, avg 23 ms) 3045 ms: void boost::io::detail::mk_str<$>(std::__cxx11::basic_string<$>&, ch... (177 times, avg 17 ms) 2314 ms: std::_Rb_tree<$>::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_... (207 times, avg 11 ms) 1923 ms: std::_Rb_tree_iterator<$> std::_Rb_tree<$>::_M_emplace_hint_unique<$... (216 times, avg 8 ms) 1817 ms: bool nlohmann::json_abi_v3_11_3::detail::parser<$>::sax_parse_intern... (18 times, avg 100 ms) 1816 ms: toml::result<$> toml::detail::sequence<$>::invoke<$>(toml::detail::l... (93 times, avg 19 ms) 1788 ms: nlohmann::json_abi_v3_11_3::detail::serializer<$>::dump(nlohmann::js... (40 times, avg 44 ms) 1749 ms: std::_Rb_tree<$>::_M_get_insert_unique_pos(std::__cxx11::basic_strin... (278 times, avg 6 ms) 1724 ms: std::__cxx11::basic_string<$>::_M_mutate(unsigned long, unsigned lon... (248 times, avg 6 ms) 1697 ms: boost::io::basic_altstringbuf<$>::overflow(int) (194 times, avg 8 ms) 1684 ms: nix::fetchers::GitInputScheme::fetch(nix::ref<$>, nix::fetchers::Inp... (1 times, avg 1684 ms) 1680 ms: std::_Rb_tree_node<$>* std::_Rb_tree<$>::_M_copy<$>(std::_Rb_tree_no... (303 times, avg 5 ms) 1589 ms: bool nlohmann::json_abi_v3_11_3::detail::parser<$>::sax_parse_intern... (18 times, avg 88 ms) 1483 ms: non-virtual thunk to boost::wrapexcept<$>::~wrapexcept() (181 times, avg 8 ms) 1447 ms: nlohmann::json_abi_v3_11_3::detail::serializer<$>::dump_escaped(std:... (40 times, avg 36 ms) 1441 ms: std::__shared_ptr<$>::~__shared_ptr() (496 times, avg 2 ms) 1420 ms: boost::stacktrace::basic_stacktrace<$>::init(unsigned long, unsigned... (137 times, avg 10 ms) 1396 ms: boost::basic_format<$>::~basic_format() (194 times, avg 7 ms) 1290 ms: std::__cxx11::basic_string<$>::_M_replace_cold(char*, unsigned long,... (231 times, avg 5 ms) 1258 ms: std::vector<$>::~vector() (354 times, avg 3 ms) 1222 ms: std::__cxx11::basic_string<$>::_M_replace(unsigned long, unsigned lo... (231 times, avg 5 ms) 1194 ms: std::_Rb_tree<$>::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_... (49 times, avg 24 ms) 1186 ms: bool tao::pegtl::internal::sor<$>::match<$>(std::integer_sequence<$>... (1 times, avg 1186 ms) 1149 ms: std::__detail::_Executor<$>::_M_dfs(std::__detail::_Executor<$>::_Ma... (70 times, avg 16 ms) 1123 ms: toml::detail::sequence<$>::invoke(toml::detail::location&) (69 times, avg 16 ms) 1110 ms: nlohmann::json_abi_v3_11_3::basic_json<$>::json_value::destroy(nlohm... (55 times, avg 20 ms) 1079 ms: std::_Function_handler<$>::_M_manager(std::_Any_data&, std::_Any_dat... (541 times, avg 1 ms) 1033 ms: nlohmann::json_abi_v3_11_3::detail::lexer<$>::scan_number() (20 times, avg 51 ms) Change-Id: I10af282bcd4fc39c2d3caae3453e599e4639c70b
2024-08-26treewide: fix a bunch of lintsJade Lovelace
Fixes: - Identifiers starting with _ are prohibited - Some driveby header dependency cleaning which wound up with doing some extra fixups. - Fucking C style casts, man. C++ made these 1000% worse by letting you also do memory corruption with them with references. - Remove casts to Expr * where ExprBlackHole is an incomplete type by introducing an explicitly-cast eBlackHoleAddr as Expr *. - An incredibly illegal cast of the text bytes of the StorePath hash into a size_t directly. You can't DO THAT. Replaced with actually parsing the hash so we get 100% of the bits being entropy, then memcpying the start of the hash. If this shows up in a profile we should just make the hash parser faster with a lookup table or something sensible like that. - This horrendous bit of UB which I thankfully slapped a deprecation warning on, built, and it didn't trigger anywhere so it was dead code and I just deleted it. But holy crap you *cannot* do that. inline void mkString(const Symbol & s) { mkString(((const std::string &) s).c_str()); } - Some wrong lints. Lots of wrong macro lints, one wrong suspicious-sizeof lint triggered by the template being instantiated with only pointers, but the calculation being correct for both pointers and not-pointers. - Exceptions in destructors strike again. I tried to catch the exceptions that might actually happen rather than all the exceptions imaginable. We can let the runtime hard-kill it on other exceptions imo. Change-Id: I71761620846cba64d66ee7ca231b20c061e69710
2024-08-21libutil/config: unify path setting typesAlois Wohlschlager
There have been multiple setting types for paths that are supposed to be canonicalised, depending on whether zero or one, one, or any number of paths is to be specified. Naturally, they behaved in slightly different ways in the code. Simplify things by unifying them and removing special behaviour (mainly the "multiple paths type can coerce to boolean" thing). Change-Id: I7c1ce95e9c8e1829a866fb37d679e167811e9705
2024-08-21libexpr: Soft-deprecate ancient let syntaxpiegames
Change-Id: I6802b26f038578870ea1fa1ed298f0c4b1f29c4a
2024-08-21libexpr: Soft-deprecate __overridespiegames
Change-Id: I787e69e1dad6edc5ccdb747b74a9ccd6e8e13bb3
2024-08-19flake: don't refetch unmodified inputs by recursive followsMaximilian Bosch
Closes #460 I managed to trigger the issue by having the following inputs (shortened): authentik-nix.url = "github:nix-community/authentik-nix"; authentik-nix.inputs.poetry2nix.inputs.nixpkgs.follows = "nixpkgs"; When evaluating this using nix-eval-jobs --flake .#hydraJobs I got the following error: error: cannot update unlocked flake input 'authentik-nix/poetry2nix' in pure mode The issue we have here is that `authentik-nix/poetry2nix` was written into the `overrideMap` which caused Nix to assume it's a new input and tried to refetch it (#460) or errored out in pure mode (nix-eval-jobs / Hydra). The testcase unfortunately only involves checking for the output log and makes sure that something *is* logged on the first fetch so that the test doesn't rot when the logging changes since I didn't manage to trigger the error above with the reproducer from #460. In fact, I only managed to trigger the `cannot update unlocked flake input` error in this context with `nix-eval-jobs`. Change-Id: Ifd00091eec9a0067ed4bb3e5765a15d027328807
2024-08-17libexpr: Deprecate URL literalspiegames
Closes #437. Change-Id: I9f67fc965bb4a7e7fd849e5067ac1cb3bab064cd
2024-08-17libexpr: Introduce Deprecated featurespiegames
They are like experimental features, but opt-in instead of opt-out. They will allow us to gracefully remove language features. See #437 Change-Id: I9ca04cc48e6926750c4d622c2b229b25cc142c42
2024-08-08libexpr: move Value implementations out of eval.ccQyriad
Change-Id: I2ce8a9713533888b3d109a56947156eb3a5ab492
2024-08-08Merge changes I526cceed,Ia4e2f1fa,I22e66972,I9fbd55a9,Ifca22e44 into mainjade
* changes: sqlite: add a Use::fromStrNullable util: implement charptr_cast tree-wide: fix a pile of lints refactor: make HashType and Base enum classes for type safety build: integrate clang-tidy into CI
2024-08-08tree-wide: fix a pile of lintsJade Lovelace
This: - Converts a bunch of C style casts into C++ casts. - Removes some very silly pointer subtraction code (which is no more or less busted on i686 than it began) - Fixes some "technically UB" that never had to be UB in the first place. - Makes finally follow the noexcept status of the inner function. Maybe in the future we should ban the function from not being noexcept, but that is not today. - Makes various locally-used exceptions inherit from std::exception. Change-Id: I22e66972602604989b5e494fd940b93e0e6e9297
2024-08-08refactor: make HashType and Base enum classes for type safetyJade Lovelace
Change-Id: I9fbd55a9d50464a56fe11cb42a06a206914150d8
2024-08-08libexpr: Add experimental pipe operatorpiegames
The |> operator is a reverse function operator with low binding strength to replace lib.pipe. Implements RFC 148, see the RFC text for more details. Closes #438. Change-Id: I21df66e8014e0d4dd9753dd038560a2b0b7fd805
2024-08-07libexpr/parser: Test experimental featurespiegames
Currently, the parser relies on the global experimental feature flags. In order to properly test conditional language features, we instead need to pass it around in the parser::State. This means that the parser cannot cache the result of isEnabled anymore, which wouldn't necessarily hurt performance if the function didn't perform a linear search on the list of enabled features on every single call. While we could simply evaluate once at the start of parsing and cache the result in the parser state, the more sustainable solution would be to fix `isEnabled` such that all callers may profit from the performance improvement. Change-Id: Ic9b9c5d882b6270e1114988b63e6064d36c25cf2
2024-08-07Merge "fix: warn and document when advanced attributes will have no impact ↵Maximilian Bosch
due to __structuredAttrs" into main
2024-08-07Merge "package: improve support for building without BDW-GC" into mainalois31
2024-08-04tree-wide: fix various lint warningsJade Lovelace
Change-Id: I0fc80718eb7e02d84cc4b5d5deec4c0f41116134
2024-08-03fix: warn and document when advanced attributes will have no impact due to ↵Tom Bereknyei
__structuredAttrs Backport of https://github.com/NixOS/nix/pull/10884. Change-Id: I82cc2794730ae9f4a9b7df0185ed0aea83efb65a
2024-08-03package: improve support for building without BDW-GCAlois Wohlschlager
Expose an option for disabling the BDW-GC build dependency entirely. Fix the place where one of its headers was included (unnecessarily) without proper guarding. Finally, use this machinery to exclude BDW-GC from the ASAN builds entirely (its usage has already been disabled due to compatibility issues anyway), to ensure this configuration is not regressed again. Change-Id: I2ebe8094abf67e7d1e99eed971de3e99d071c10b
2024-08-02Merge "Reapply "libfetchers: make attribute / URL query handling ↵Maximilian Bosch
consistent"" into main
2024-08-01Reapply "libfetchers: make attribute / URL query handling consistent"Maximilian Bosch
The original attempt at this introduced a regression; this commit reverts the revert and fixes the regression. This reverts commit 3e151d4d77b5296b9da8c3ad209932d1dfa44c68. Fix to the regression: flakeref: fix handling of `?dir=` param for flakes in subdirs As reported in #419[1], accessing a flake in a subdir of a Git repository fails with the previous commit[2] applied with the error error: unsupported Git input attribute 'dir' The problem is that the `dir`-param is inserted into the parsed URL if a flake is fetched from the subdir of a Git repository. However, for the fetching part this isn't even needed. The fix is to just pass `subdir` as second argument to `FlakeRef` (which needs a `basedir` that can be empty) and leave the parsedURL as-is. Added a regression test to make sure we don't run into this again. [1] https://git.lix.systems/lix-project/lix/issues/419 [2] e22172aaf6b6a366cecd3c025590e68fa2b91bcc, originally 3e151d4d77b5296b9da8c3ad209932d1dfa44c68 Change-Id: I2c72d5a32e406a7ca308e271730bd0af01c5d18b
2024-08-01Merge changes Icc4747ae,Id4717b5b,Ie3ddb3d0,Ic4d93a08,I00d9ff70 into mainQyriad
* changes: remove unused headers in installable-attr-path libexpr: include the type of the non-derivation value in the type error libexpr: mild cleanup to getDerivations libexpr: DrvInfo: remove unused bad-citizen constructor cleanup and slightly refactor DrvInfo::queryOutputs
2024-08-01libexpr: include the type of the non-derivation value in the type errorQyriad
Change-Id: Id4717b5b0df7c09b0dbf17e642d8713a0a3efbae
2024-08-01libexpr: mild cleanup to getDerivationsQyriad
Shuffled the logic around a bit so the shorter code paths are early returns, added comments, etc. Should be NFC. Change-Id: Ie3ddb3d0eddd614d6f8c37bf9a4d5a50282084ea
2024-08-01libexpr: DrvInfo: remove unused bad-citizen constructorQyriad
DrvInfo's constructor that only takes `EvalState` leaves everything else empty; a DrvInfo which has no iota of information about the derivation it represents is not useful, and was not used anywhere. Change-Id: Ic4d93a08cb2748b8cef9a61e41e70404834b23f9
2024-08-01cleanup and slightly refactor DrvInfo::queryOutputsQyriad
Change-Id: I00d9ff707fe61995737b86af6d2eaa1e4d8116ff
2024-07-31libexpr: implement actual constructors for nix::ValueQyriad
Change-Id: Iebc2bb4e4ea5e93045afe47677df756de4ec4d05
2024-07-22Merge "libexpr/gc-alloc: fix compilation with !HAVE_BOEHMGC" into mainPierre Bourdon
2024-07-23libexpr/gc-alloc: fix compilation with !HAVE_BOEHMGCPierre Bourdon
Fixes: 72ee25b4025257fdaab7b8e8d5d1ccc83858fdab Change-Id: Ib59386af1415a8ed4b53af24ec22a4ffa5e5877d
2024-07-22enable -Werror=suggest-overrideeldritch horrors
*accidentally* overriding a function is almost guaranteed to be an error. overriding a function without labeling it as such is merely bad style, but bad style that makes the code harder to understand. Change-Id: Ic0594f3d1604ab6b3c1a75cb5facc246effe45f0
2024-07-22libexpr: fix -Wunused-const-variable warningeldritch horrors
Change-Id: Ib986ece0ab2eff83e7abd7f1f915cd8f761827ad
2024-07-20libexpr: add a strongly typed version of gcAllocBytes()Qyriad
This commit adds a new helper template function to gc-alloc.hh (which is probably where you want to look at first, O great reviewer [custom file ordering in review diffs when]), which uses a type argument to determine the size to allocate, rather than making the caller use sizeof(). Change-Id: Ib5d138d91a28bdda304a80db24ea9fb08669ad22
2024-07-20libexpr: rename confusing makeImmutableString -> gcCopyStringIfNeededQyriad
The purpose of this function has little to do with immutability. Value's strings are never mutated, and the point of this function is to singleton empty strings. Change-Id: Ifd41dd952409d54e4d3de9ab59064e6928b0e480
2024-07-20libexpr: refactor gc-agnostic helpers into one placeQyriad
Change-Id: Icc4b367e4f670d47256f62a3a002cd248a5c2d3b
2024-07-19Merge changes Id8b3d289,Ib75ab5b8,I3792eeb3 into mainjade
* changes: Fixup a bunch of references to nixos.org manuals Add release notes for removing overflow from Nix language expr: fix a compiler warning about different signs in comparison
2024-07-18Fixup a bunch of references to nixos.org manualsJade Lovelace
(plus one reference to CppNix github) Change-Id: Id8b3d2897f3b54e286861805cfd421adc4d5de47
2024-07-18expr: fix a compiler warning about different signs in comparisonJade Lovelace
We know that variable is >=0, so we can just cast it to unsigned. Change-Id: I3792eeb3ca43e6a507cc44c1a70584d42b2acd7b
2024-07-18libexpr/print: do not show elided nested items when there are noneAlois Wohlschlager
When the configured maximum depth has been reached, attribute sets and lists are printed with ellipsis to indicate the elision of nested items. Previously, this happened even in case the structure being printed is empty, so that such items do not in fact exist. This is confusing, so stop doing it. Change-Id: I0016970dad3e42625e085dc896e6f476b21226c9
2024-07-18libexpr/print: never show empty attrsets or derivations as «repeated»Alois Wohlschlager
The repeated value detection logic exists so that the occurrence of large common substructures does not fill up the screen or the computer's memory. However, empty attribute sets and derivations (when their detection is enabled) are always cheap to print, and in practice I have observed them to make up a significant majority of the cases where I was annoyed by the repeated value detection kicking in. Furthermore, `nix-instantiate --eval` already disables this logic for empty attribute sets, and empty lists are already exempted everywhere. For these reasons, always print empty attribute sets and derivations as what they are. Change-Id: I5dac8e7739f9d726b76fd0521ec46f38af94463f
2024-07-18libexpr/print: pretty-print idempotentlyAlois Wohlschlager
When pretty-printing is enabled, previously an unforced thunk would trigger indentation, even when it subsequently does not evaluate to a nested structure. The resulting output looked inconsistent, and furthermore pretty-printing was not idempotent (since pretty-printing the same value again, which is now fully evaluated, will not trigger indentation). When strict evaluation is enabled, force the item before inspecting its type, so that it is properly known whether it contains a nested structure. Furthermore, there is no need to cause indentation for unforced thunks, since the very next operation will be printing them as `«thunk»`. This is mostly a port of https://github.com/NixOS/nix/pull/11100 , but we only force the item when it's going to be forced anyway due to strict pretty-printing, and a new test was written since the REPL testing framework in Lix is different. Co-Authored-By: Robert Hensing <robert@roberthensing.nl> Change-Id: Ib7560fe531d09e05ca6b2037a523fe21a26d9d58
2024-07-16remove boost coroutine referenceseldritch horrors
we no longer need these since sinkToSource and sourceToSink are gone. Change-Id: Ibbf440e2cf71bf3e9f3b833af2d78a21fb1b3193
2024-07-16remove sourceToSink, sinkToSource, and boehm patcheldritch horrors
Change-Id: I1379841299713175d0225b82a67f50660f9eb5e2
2024-07-14libexpr/eval.cc: remove unnecessary C string conversionNaN
Change-Id: I5b7c21df84ff8ff64cf6a1e261fc3729a06bd4f6
2024-07-13language: cleanly ban integer overflowsJade Lovelace
This also bans various sneaking of negative numbers from the language into unsuspecting builtins as was exposed while auditing the consequences of changing the Nix language integer type to a newtype. It's unlikely that this change comprehensively ensures correctness when passing integers out of the Nix language and we should probably add a checked-narrowing function or something similar, but that's out of scope for the immediate change. During the development of this I found a few fun facts about the language: - You could overflow integers by converting from unsigned JSON values. - You could overflow unsigned integers by converting negative numbers into them when going into Nix config, into fetchTree, and into flake inputs. The flake inputs and Nix config cannot actually be tested properly since they both ban thunks, however, we put in checks anyway because it's possible these could somehow be used to do such shenanigans some other way. Note that Lix has banned Nix language integer overflows since the very first public beta, but threw a SIGILL about them because we run with -fsanitize=signed-overflow -fsanitize-undefined-trap-on-error in production builds. Since the Nix language uses signed integers, overflow was simply undefined behaviour, and since we defined that to trap, it did. Trapping on it was a bad UX, but we didn't even entirely notice that we had done this at all until it was reported as a bug a couple of months later (which is, to be fair, that flag working as intended), and it's got enough production time that, aside from code that is IMHO buggy (and which is, in any case, not in nixpkgs) such as https://git.lix.systems/lix-project/lix/issues/445, we don't think anyone doing anything reasonable actually depends on wrapping overflow. Even for weird use cases such as doing funny bit crimes, it doesn't make sense IMO to have wrapping behaviour, since two's complement arithmetic overflow behaviour is so *aggressively* not what you want for *any* kind of mathematics/algorithms. The Nix language exists for package management, a domain where bit crimes are already only dubiously in scope to begin with, and it makes a lot more sense for that domain for the integers to never lose precision, either by throwing errors if they would, or by being arbitrary-precision. This change will be ported to CppNix as well, to maintain language consistency. Fixes: https://git.lix.systems/lix-project/lix/issues/423 Change-Id: I51f253840c4af2ea5422b8a420aa5fafbf8fae75
2024-07-12Use std::strong_ordering for version comparisonJade Lovelace
The actual motive here is the avoidance of integer overflow if we were to make these use checked NixInts and retain the subtraction. However, the actual *intent* of this code is a three-way comparison, which can be done with operator<=>, so we should just do *that* instead. Change-Id: I7f9a7da1f3176424b528af6d1b4f1591e4ab26bf
2024-07-08libexpr: stop lying about DrvInfo's constnessQyriad
DrvInfo's query methods all use mutable fields to cache, but like. that's basically the entire interface for DrvInfo. Not only that, but these formerly-const-marked functions can even throw due to eval errors! Changing this only required removing some `const` markers in nix-env, and changing a single inline `queryInstalled()` call to be an lvalue instead. Change-Id: I796807118f3b35b0e93668b5e28210d9e521b2ae
2024-07-04mildly cleanup libexpr/eval.hhQyriad
Change-Id: I40d01a8f8b7fb101279c6f88ebdf1f0969d9d7f0
2024-07-04distinguish between throws & errors during throwQyriad
Turns errors like this: let throwMsg = a: throw (a + " invalid bar"); in throwMsg "bullshit" error: … from call site at «string»:3:4: 2| throwMsg = a: throw (a + " invalid bar"); 3| in throwMsg "bullshit" | ^ … while calling 'throwMsg' at «string»:2:14: 1| let 2| throwMsg = a: throw (a + " invalid bar"); | ^ 3| in throwMsg "bullshit" … while calling the 'throw' builtin at «string»:2:17: 1| let 2| throwMsg = a: throw (a + " invalid bar"); | ^ 3| in throwMsg "bullshit" error: bullshit invalid bar into errors like this: let throwMsg = a: throw (a + " invalid bar"); in throwMsg "bullshit" error: … from call site at «string»:3:4: 2| throwMsg = a: throw (a + " invalid bar"); 3| in throwMsg "bullshit" | ^ … while calling 'throwMsg' at «string»:2:14: 1| let 2| throwMsg = a: throw (a + " invalid bar"); | ^ 3| in throwMsg "bullshit" … caused by explicit throw at «string»:2:17: 1| let 2| throwMsg = a: throw (a + " invalid bar"); | ^ 3| in throwMsg "bullshit" error: bullshit invalid bar Change-Id: I593688928ece20f97999d1bf03b2b46d9ac338cb
2024-07-04trace which part of `foo.bar.baz` errorsQyriad
Turns errors like: let somepkg.src = throw "invalid foobar"; in somepkg.src.meta error: … while evaluating the attribute 'src.meta' at «string»:2:3: 1| let 2| somepkg.src = throw "invalid foobar"; | ^ 3| in somepkg.src.meta … while calling the 'throw' builtin at «string»:2:17: 1| let 2| somepkg.src = throw "invalid foobar"; | ^ 3| in somepkg.src.meta error: invalid foobar into errors like: let somepkg.src = throw "invalid foobar"; in somepkg.src.meta error: … while evaluating the attribute 'src.meta' at «string»:2:3: 1| let 2| somepkg.src = throw "invalid foobar"; | ^ 3| in somepkg.src.meta … while evaluating 'somepkg.src' to select 'meta' on it at «string»:3:4: 2| somepkg.src = throw "invalid foobar"; 3| in somepkg.src.meta | ^ … while calling the 'throw' builtin at «string»:2:17: 1| let 2| somepkg.src = throw "invalid foobar"; | ^ 3| in somepkg.src.meta error: invalid foobar And for type errors, from: let somepkg.src = "I'm not an attrset"; in somepkg.src.meta error: … while evaluating the attribute 'src.meta' at «string»:2:3: 1| let 2| somepkg.src = "I'm not an attrset"; | ^ 3| in somepkg.src.meta … while selecting an attribute at «string»:3:4: 2| somepkg.src = "I'm not an attrset"; 3| in somepkg.src.meta | ^ error: expected a set but found a string: "I'm not an attrset" into: let somepkg.src = "I'm not an attrset"; in somepkg.src.meta error: … while evaluating the attribute 'src.meta' at «string»:2:3: 1| let 2| somepkg.src = "I'm not an attrset"; | ^ 3| in somepkg.src.meta … while selecting 'meta' on 'somepkg.src' at «string»:3:4: 2| somepkg.src = "I'm not an attrset"; 3| in somepkg.src.meta | ^ error: expected a set but found a string: "I'm not an attrset" For the low price of an enumerate() and a lambda you too can have the incorrect line of code actually show up in the trace! Change-Id: Ic1491c86e33c167891bdac9adad6224784760bd6