combines the very common constraint
`isInputRange!R && !isInfinite!R && isSomeChar!(ElementEncodingType!R)`
and adds a bunch of documentation with examples for users to understand
it better. This should lower the neccessary needed technical insight to
read basic docs, especially std.path and std.file docs.
The buffer is initialized from right-to-left in initialize(), and unused
bytes are left alone. Previously, the whole result wasn't preinitialized
with T.init, so the unused buffer bytes weren't well-defined. Initialize
it now (with zeros), as the whole buffer is still used for equality/
identity comparisons etc.
First of all, the DDoc currently says that:
"Leading zero is allowed, but not required."
The current implementation doesn't respect that.
D lexer allows leading zero(s) also.
And when considering octal from string, there is no possibility
of confusion, as the comments in the code claim. Disallowing
leading zeros for octal conversion from string, does not help
with anything actually.
So lets allow leading zeros.
Allowing leading zeros, does help when implementing various
APIs (i.e. glibc, Linux kernel), where a lot of octal constant,
are defined with multiple leading zeros, for readability and
alignment, in C headers. Having to manually or automatically
special case these when porting such API definitions, is
counter-productive.
Example from a Linux kernel (`include/uapi/linux/stat.h`):
```c
#define S_IFMT 00170000
#define S_IFSOCK 0140000
#define S_IFLNK 0120000
#define S_IFREG 0100000
#define S_IFBLK 0060000
#define S_IFDIR 0040000
#define S_IFCHR 0020000
#define S_IFIFO 0010000
#define S_ISUID 0004000
#define S_ISGID 0002000
#define S_ISVTX 0001000
```
With this patch, now it is trivial and easier to convert these to D:
```d
...
enum S_ISVTX = octal!"0001000";
```
while being close to original. That helps with readability,
and long term maintenance.
In fact the run-time version provided by `parse!(int)(string, 8)`
also supports leading zeros already. So this makes `octal`
more consistent `parse`.
For example:
Evaluating `to!(int[])("")`
Leads to `ConvException` with message:
`Can't parse string: unexpected end of input when expecting"["`
but should be
`Can't parse string: unexpected end of input when expecting "["`
Where it has been moved to. Also get rid of the corresponding tests
in Phobos, an exact copy is in druntime (+ more forward tests).
Also extend a `scoped` test to make sure it properly forwards
r/lvalue-ness of its arguments. This required dlang/druntime#3352
and thus wasn't added in dlang/phobos#7776 directly.
The emplace() stuff was moved to druntime; for some reason, it's still
in Phobos.
I've diffed the two versions, and they are still almost identical (incl.
unittests); the druntime version appears to have seen some improvements
(e.g., forwarding r/lvalueness of the arguments) in the meantime.
This fixes failing unittests with dlang/dmd#11387 on Linux x64 by
appending a L suffix to (some) literals, to keep full `real` parsing
precision (instead of double precision).
std.format with separator and double causes RangeError
trying to find the win32 bug
windows nan -nan fix
harder workaround
name clash fix
moving some stuff around
making it shorter
oh win32_64 what are you doing to me
and another try
some windows special case
and another
and again
removed some duplicated code
make it compile again
some debug output
I need a win32_64 box
and again
better infos
finding the failing test
something strange is going on
getting closer
I got it maybe
less output
I think I understand now
tighter code
making the commit nicer
removed an import
undoing some debug changes
removed an unneeded test
Parsing as the string element type (char, in non-autodecode mode) does
not allow fitting the result of parsing escapes. Those always need to
be parsed into a dchar.
