This is already done by coerceToString(), provided that the argument
is a path (e.g. 'fetchGit ./bla'). It fixes the handling of URLs like
git@github.com:owner/repo.git. It breaks 'fetchGit "./bla"', but that
was never intended to work anyway and is inconsistent with other
builtin functions (e.g. 'readFile "./bla"' fails).
--
9c6654a316935ab097ccf462d506c02626373f0a by Tom Manshreck <shreck@google.com>:
Update comment on CUnescape() to note on failure it leaves its output param in an unspecified state.
PiperOrigin-RevId: 210956338
GitOrigin-RevId: 9c6654a316935ab097ccf462d506c02626373f0a
Change-Id: Icf0aea66afb413a0334df27960f75387087c6629
E.g.
$ nix upgrade-nix
error: directory '/home/eelco/Dev/nix/inst/bin' does not appear to be part of a Nix profile
instead of
$ nix upgrade-nix
error: '/home/eelco/Dev/nix/inst' is not a symlink
--
ed4be0cb9a708158187a0628c1c2167ae6783274 by Greg Falcon <gfalcon@google.com>:
Refactor a string unit test into a template function for internal purposes.
PiperOrigin-RevId: 210798880
--
e4c734be903ac7b3a88caf4b17909343c283a21a by Abseil Team <absl-team@google.com>:
Add a note that the RFC3339_* format specifiers use %Y, and so
do not produce 4-digit years on output nor require 4-digit years
on input, as a strict reading of RFC3339 might require.
PiperOrigin-RevId: 210785544
--
cfb5e32f9397e49ddb731445a191b36652fe2f6d by Greg Falcon <gfalcon@google.com>:
Refactor a string unit test into a template function for internal purposes.
PiperOrigin-RevId: 210776525
--
105ee700e62869cfda2a37e6f7c2ea483f8fc75e by Xiaoyi Zhang <zhangxy@google.com>:
Correctly define ABSL_HAVE_STD_STRING_VIEW for MSVC 2017. Currently the macro
is not defined even though MSVC 2017 provides `std::string_view`, and this
means both `absl::string_view` and `std::string_view` exist as distinct types.
A bunch of places relying on the false assumption that
`string_view::const_iterator` is `const char*` have to be fixed to build
successfully.
See related github issue https://github.com/abseil/abseil-cpp/issues/161.
PiperOrigin-RevId: 210764947
GitOrigin-RevId: ed4be0cb9a708158187a0628c1c2167ae6783274
Change-Id: I7a9658b3201aa669db9d3d90474feb08072718c7
Fix a 32-bit overflow that resulted in negative numbers being printed;
use fmt() instead of boost::format(); change -H to -h for consistency
with 'ls' and 'du'; make the columns narrower (since they can't be
bigger than 1024.0).
If the user has an object greater than 1024 yottabytes, it'll just display it as
N yottabytes instead of overflowing.
Swaps to use boost::format strings instead of std::setw and std::setprecision.
--
a371d3d4e213c65354dd0e8b1aa28673455aec2a by Matt Armstrong <marmstrong@google.com>:
Fix the C++17 build of absl/types/internal/variant.h.
If ABSL_HAVE_STD_VARIANT is defined this header is now a
nop. While no code should include this header in that case,
the build system may still try to compile it, for example,
if the Bazel parse_headers feature is on.
PiperOrigin-RevId: 210544253
GitOrigin-RevId: a371d3d4e213c65354dd0e8b1aa28673455aec2a
Change-Id: I9c02018b86293b7235fcc9e03fb54f1d86c4b096
Using a 64bit integer on 32bit systems will come with a bit of a
performance overhead, but given that Nix doesn't use a lot of integers
compared to other types, I think the overhead is negligible also
considering that 32bit systems are in decline.
The biggest advantage however is that when we use a consistent integer
size across all platforms it's less likely that we miss things that we
break due to that. One example would be:
https://github.com/NixOS/nixpkgs/pull/44233
On Hydra it will evaluate, because the evaluator runs on a 64bit
machine, but when evaluating the same on a 32bit machine it will fail,
so using 64bit integers should make that consistent.
While the change of the type in value.hh is rather easy to do, we have a
few more options available for doing the conversion in the lexer:
* Via an #ifdef on the architecture and using strtol() or strtoll()
accordingly depending on which architecture we are. For the #ifdef
we would need another AX_COMPILE_CHECK_SIZEOF in configure.ac.
* Using istringstream, which would involve copying the value.
* As we're already using boost, lexical_cast might be a good idea.
Spoiler: I went for the latter, first of all because lexical_cast does
have an overload for const char* and second of all, because it doesn't
involve copying around the input string. Also, because istringstream
seems to come with a bigger overhead than boost::lexical_cast:
https://www.boost.org/doc/libs/release/doc/html/boost_lexical_cast/performance.html
The first method (still using strtol/strtoll) also wasn't something I
pursued further, because it is also locale-aware which I doubt is what
we want, given that the regex for int is [0-9]+.
Signed-off-by: aszlig <aszlig@nix.build>
Fixes: #2339
