[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #28 from Dlang Bot  ---
dlang/druntime pull request #3286 "[dmd-cxx] Update bindings for FreeBSD 12
support" was merged into dmd-cxx:

- 45d33cb42369eaa6c5c9b882075892c147dd2c39 by Iain Buclaw:
  Issue 17596: Version bindings so that they work for both FreeBSD 11 and 12.

https://github.com/dlang/druntime/pull/3286

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

Iain Buclaw  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org

--- Comment #27 from Iain Buclaw  ---
So, I'm not having any trouble building dmd on FreeBSD 12.2 using
AUTO_BOOTSTRAP=1 DFLAGS=-version=TARGET_FREEBSD12

After the half dozen or so PRs, the CI pipeline for FreeBSD 12 is not reporting
any testsuite or unittest failures either, so I think this is now resolved.

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #26 from Dlang Bot  ---
dlang/druntime pull request #3271 "Issue 17596: Version bindings so that they
work for both FreeBSD 11 and 12" was merged into master:

- 0dd4243100275a6969b5cdc24da68831d3f65599 by Iain Buclaw:
  Issue 17596: Version bindings so that they work for both FreeBSD 11 and 12.

https://github.com/dlang/druntime/pull/3271

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #25 from Dlang Bot  ---
@ibuclaw created dlang/druntime pull request #3271 "Issue 17596: Version
bindings so that they work for both FreeBSD 11 and 12" mentioning this issue:

- Issue 17596: Version bindings so that they work for both FreeBSD 11 and 12.

https://github.com/dlang/druntime/pull/3271

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #24 from Cy Schubert  ---
I've had no choice but to deorbit the dmd2 port as it has been marked broken
for more than 6 months. We can always resurrect it later though.

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #23 from Jonathan M Davis  ---
And this is my PR with the binding changes that are required to get the
druntime and Phobos unit tests and the dmd test suite passing:

https://github.com/dlang/druntime/pull/2280

(In reply to Martin Nowak from comment #22)
> What happened to the idea of runtime compat checks mentioned in comment 9?
> In particular it seems that FreeBSD's dealing with the ABI change in C
> should be fully understood before taking any measures.
> Also there are versioned symbols in FBSD12 that use the old struct layouts
> (e.g. `stat@FBSD_1.0`). We could always use those for now.
> As another option you might use the new functions and struct layouts if
> running on >=12, but translate the structs to the old layout and explicitly
> call the old versioned symbols if running on <12.

Rather than repeating myself, I'll let anyone read the discussion in the dmd PR
to get the full answer to that.

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #22 from Martin Nowak  ---
What happened to the idea of runtime compat checks mentioned in comment 9?
In particular it seems that FreeBSD's dealing with the ABI change in C should
be fully understood before taking any measures.
Also there are versioned symbols in FBSD12 that use the old struct layouts
(e.g. `stat@FBSD_1.0`). We could always use those for now.
As another option you might use the new functions and struct layouts if running
on >=12, but translate the structs to the old layout and explicitly call the
old versioned symbols if running on <12.

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #21 from Jonathan M Davis  ---
This adds version identifiers for the version of FreeBSD, which will make it
possible to version OS bindings for the version of FreeBSD where necessary:

https://github.com/dlang/dmd/pull/8567

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

Jonathan M Davis  changed:

   What|Removed |Added

 CC||issues.dl...@jmdavisprog.co
   ||m

--- Comment #20 from Jonathan M Davis  ---
(In reply to Vladimir Panteleev from comment #9)
> Alright, so how about:
> 
> - We add getosreldate and INO64_FIRST to druntime
> - We add both the old and new struct definitions
> - We add a stat wrapper which,when getosreldate() < INO64_FIRST, translates
> the old struct to the new struct and returns it.

I tried that with the functions from sys/mount.h that use statfs_t, and it
doesn't work. The problem is that from what I can tell, if you build a program
on FreeBSD 11, it runs just fine on FreeBSD 12 - at least it did with the
functions in sys/mount.h. e.g. When running a program built on FreeBSD 11 on
FreeBSD 12, fstatfs reports the same version with its f_version member that it
does on FreeBSD 11, and it clearly calls the FreeBSD 11 version of fstafs.
objdump confirms this. If you compile a C/C++ program which uses fstatfs on
FreeBSD 12 and use objdump -t on it and grep for fstatfs, it has

002013e0   F *UND*    fstatfs

whereas if you compile it on FreeBSD 11, you get

   F *UND*  0011  fstatfs@@FBSD_1.0

Building a D program that does the same thing on FreeBSD 11 also results in

   F *UND*  0011  fstatfs@@FBSD_1.0

and it still says

   F *UND*  0011  fstatfs@@FBSD_1.0

if you run objdump on it in FreeBSD 12. And it runs just fine on FreeBSD 12.

If I create a wrapper in druntime so that it uses the FreeBSD 11 version of
stat_t if getosreldate() < INO64_FIRST, then it works just fine on FreeBSD 11
but fails miserably when running that binary on FreeBSD 12, because the binary
has the FreeBSD 11 version of the function in it, and it's the FreeBSD 11
version of stat_t that it's using even though it's running on FreeBSD 12.

So, from what testing I've done thus far, running D binaries built on FreeBSD
11 on FreeBSD 12 works just fine. What fails is when you try to build a program
on FreeBSD 12 (including the compiler). The resulting binary doesn't work
properly if it uses any of the structs that changed, because the definition in
D does not match the definition in C.

It may be that taking a program built on FreeBSD 11 which uses a function like
fstatfs and running it on FreeBSD 12 only works because the OS itself detects
which version of the function your program is built with and therefore calls
the old version of the syscall internally (I don't know), but building a D
program on FreeBSD 11 and running it on 12 seems to work just fine right now,
whereas if you build anything with dmd on FreeBSD 12 where the definition in
druntime does not match the actual FreeBSD 12 definition, then it doesn't work.

So, my conclusion is that the only way to fully fix this is for the struct
definitions to be versioned based on the version of FreeBSD the program is
built on (which would then allow us to do the same thing that C/C++ does and
have versioned headers). And arguably, assuming that there's only one version
of the OS when creating bindings for the OS headers is a terrible idea to begin
with. We only really get away with it like we do because of the fact that most
of them don't change very often.

In any case, all of the extra stuff with detecting the version of FreeBSD at
runtime in D and changing which version of a struct you use based on what
getosreldate() says might make it possible to run a binary built on FreeBSD 12
(with the FreeBSD 12 versions of the structs) on FreeBSD 11 (I don't know), but
it breaks running a FreeBSD 11 binary on FreeBSD 12.

As far as I can tell, we really only have two options:

1. Make it so that dmd actually provides a version identifier for different
versions of FreeBSD (e.g. FreeBSD11 and FreeBSD12) so that we can version the
definitions in druntime just like they would be in the actual C headers (since
FreeBSD 11 gets different headers than FreeBSD 12). That way, we could version
most stuff with FreeBSD like we always have but cleanly cope when definitions
change between versions of FreeBSD by versioning those few symbols with
identifiers such as FreeBSD11 or FreeBSD12.

2. Have a PR where we change all of the struct definitions that differ between
FreeBSD 11 and FreeBSD 12, use a dmd binary built on FreeBSD 11 with the old
code to build it, and then immediately require that everything built with that
version of dmd and newer use FreeBSD 12. That's theoreticaly feasible, but it
could be difficult to make work well with the auto-tester, and it would be
fairly disruptive. This isn't like with Windows where we say that we support

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

anonymous4  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=18885

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #19 from Cy Schubert  ---
That probably makes sense. I can restrict FreeBSD 10 and 11 to an old release
of dmd. At least it addresses the issue going forward.

I'll rework the port the next time I visit it. I'm hoping to have this resolved
by the time FreeBSD 12 is released.

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

Walter Bright  changed:

   What|Removed |Added

   Severity|major   |blocker

--- Comment #18 from Walter Bright  ---
We don't seem to have a good solution for backwards compatibility, or anyone
particularly interested in supporting it. So we should just update the structs,
abandon the old FreeBSDs, and move on with the newer ones.

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #17 from anonymous4  ---
(In reply to Vladimir Panteleev from comment #4)
> dmd/src/root/file.d is now located at dmd/src/ddmd/root/file.d:
> 
> https://github.com/dlang/dmd/blob/master/src/ddmd/root/file.d#L97
File size can be determined by seeking to the end. That would be a simpler fix.

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #16 from Walter Bright  ---
This should help:

https://github.com/dlang/druntime/pull/1947

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #15 from Walter Bright  ---
(In reply to Walter Bright from comment #14)
> Is there a FreeBSD syscall that will give the version?

Looks like uname(3) does the trick:

https://www.freebsd.org/cgi/man.cgi?query=uname=3=0=FreeBSD+11.1-RELEASE+and+Ports

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #14 from Walter Bright  ---
Is there a FreeBSD syscall that will give the version?

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #13 from Cy Schubert  ---
I'll give it a try.

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #12 from alex.jercai...@gmail.com ---
Also, on FreeBSD 12 I could not build phobos or druntime with the most recent
compiler, due to segfaults while compiling barrier.d.

I could however build both druntime and phobos with the one here[1].

I think these problems are related.

[1] -
http://downloads.dlang.org/releases/2.x/2.076.1/dmd.2.076.1.freebsd-32.tar.xz

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

alex.jercai...@gmail.com changed:

   What|Removed |Added

 CC||alex.jercai...@gmail.com
   Assignee|nob...@puremagic.com|alex.jercai...@gmail.com

--- Comment #11 from alex.jercai...@gmail.com ---
Hi, I can take a look into this

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #10 from Cy Schubert  ---
Sorry about the absence. Too many projects, this one happened to be pushed down
the stack. I'm looking at this again.

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #9 from Vladimir Panteleev  ---
Alright, so how about:

- We add getosreldate and INO64_FIRST to druntime
- We add both the old and new struct definitions
- We add a stat wrapper which,when getosreldate() < INO64_FIRST, translates the
old struct to the new struct and returns it.

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #8 from Cy Schubert  ---
Sorry for not replying sooner, way too many projects on the go here.

Here is how kib supported older apps prior to inode64:

https://svnweb.freebsd.org/base?view=revision=318736

Forward compatibility:

https://svnweb.freebsd.org/base?view=revision=320278

Stat.c, below, relies on versioned symbols (see
https://svnweb.freebsd.org/base/head/lib/libprocstat/Symbol.map?r1=318736=318735=318736)

int
stat(const char *path, struct stat *sb)
{
struct freebsd11_stat stat11;
int rv;

if (__getosreldate() >= INO64_FIRST)
return (__sys_fstatat(AT_FDCWD, path, sb, 0));
rv = syscall(SYS_freebsd11_stat, path, );
if (rv == 0)
__stat11_to_stat(, sb);
return (rv);
}

IMO implementing it in this way would require architectural changes to D's
implementation of some syscalls, similar to how Perl might interface with the
O/S. Discussing this with the maintainer of the ldc port, the short term
solution might be for he and I to patch the ports, however that would be a
fragile solution as depending on the options used at FreeBSD build time, stat_t
and dirent_t may vary.

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

Nemanja Boric <4bur...@gmail.com> changed:

   What|Removed |Added

 CC||4bur...@gmail.com

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #7 from Vladimir Panteleev  ---
(In reply to Cy Schubert from comment #5)
> What do you think if DMD D and LDC D provided a facility to test
> __FreeBSD_version or if not that the major.minor version number?

Cy, you mentioned that the patch came with careful backwards compatibility
provisions so as not to break older binaries. In my previous comment I asked
how that compatibility check works, and whether we can take advantage of it.
Have you looked into that at all yet?

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #6 from anonymous4  ---
see https://github.com/freebsd/freebsd/blob/master/lib/libc/gen/gen-compat.h

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #5 from Cy Schubert  ---
Thanks. I'll develop a patch (will take some time -- I have a number of
projects on the fly at the moment). The patch will will work for FreeBSD 12
after r318736 but break all FreeBSD releases prior to that. This is not
optimal. Is there a version() statement that will allow me to test for FreeBSD
version or can DMD read /usr/include/sys/param.h for the C pre-processor define
of __FreeBSD_version?

Also, it appears that ldc (DMD D with an llvm backend, see
http://wiki.dlang.org/LDC) has the same segfault under FreeBSD 12. I don't
maintain it for the FreeBSD project but it too suffers the same segfault. Maybe
a more holistic approach needs to be taken than a simple point patch.
Eventually when FreeBSD 12 is released to the public there will be two
different stat_t and dirent_t data structures (pre- and post-inode64). What do
you think if DMD D and LDC D provided a facility to test __FreeBSD_version or
if not that the major.minor version number? No matter what we do we will break
old or new systems.

If you can provide a version() statement that can test for either
__FreeBSD_version in /usr/include/sys/param.h (preferred) or the FreeBSD
major.minor version number, any patch I produce will work for both. (I kind of
think this might be useful for most other O/S's too, e.g. RHEL 6 v.s. RHEL 7,
though the test would be very different for each.)

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #4 from Vladimir Panteleev  ---
(In reply to Cy Schubert from comment #3)
> The implementer of inode64 has done a great job of avoiding ABI breakage.
> Applications built before inode64 continue to run due to code in libc to
> detect "old" v.s. "new". Most newly compiled code builds and runs okay. DMD
> is different however because many data structures are replicated in DMD. For
> example stat_t and dirent_t headers have issues.

How does the old/new detection work? Does it look at the ELF timestamp, or
something like that?

Because D has binary releases for FreeBSD (and compiling it from source is a
bit onerous as it requires bootstrapping through an older version of D), we
will probably want to ensure, if possible, that the binary D releases will work
on both new and old versions of the system for a while. This likely means that
we would want to use the old fstat ABI exclusively for a few years, so if it's
possible to opt in to the old ABI, that would probably be the way to go for
now.

Is the new functionality available via a new function akin to fstat64 on Linux?

> I wasn't able to find a stub that DMD D might use to make the actual call.
> If you can point me in the right direction I should be able to do the work
> myself (when I can find the time).

dmd/src/root/file.d is now located at dmd/src/ddmd/root/file.d:

https://github.com/dlang/dmd/blob/master/src/ddmd/root/file.d#L97

For FreeBSD, fstat is defined here:

https://github.com/dlang/druntime/blob/master/src/core/sys/posix/sys/stat.d#L1207

and stat_t here:

https://github.com/dlang/druntime/blob/master/src/core/sys/posix/sys/stat.d#L730-L758

Finally, ino_t is defined here:

https://github.com/dlang/druntime/blob/master/src/core/sys/posix/sys/types.d#L135

I believe that fstat is called by linking to the respective libc, i.e. D does
not perform the syscall directly.

> Having said that, any change would be incompatible with older releases of
> FreeBSD so, a possible solution might be a version check for
> version(FreeBSD12+) -- (FreeBSD uses a version check in
> /usr/include/sys/param.h.) Is there a way to determine which release of
> FreeBSD within DMD D? Such as version(something)?

Not as far as I know. I guess it would require changing the compiler to detect
the FreeBSD release and enable a corresponding version, which would also need
to be added.

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #3 from Cy Schubert  ---
Correct.

The implementer of inode64 has done a great job of avoiding ABI breakage.
Applications built before inode64 continue to run due to code in libc to detect
"old" v.s. "new". Most newly compiled code builds and runs okay. DMD is
different however because many data structures are replicated in DMD. For
example stat_t and dirent_t headers have issues.

I wasn't able to find a stub that DMD D might use to make the actual call. If
you can point me in the right direction I should be able to do the work myself
(when I can find the time).

Having said that, any change would be incompatible with older releases of
FreeBSD so, a possible solution might be a version check for
version(FreeBSD12+) -- (FreeBSD uses a version check in
/usr/include/sys/param.h.) Is there a way to determine which release of FreeBSD
within DMD D? Such as version(something)?

So summarize my thoughts above:

1. The data structures and files that use inodes system calls to stat(), fstat,
and others need to be identified. I can do some of the work or we can work
together.

2. Some way of identifying "old" FreeBSD v.s. "new" FreeBSD through a version
check.

Hopefully this is not too much information (as I tend to get into the weeds).

~cy

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #2 from Vladimir Panteleev  ---
I don't know much about FreeBSD, but do I understand correctly that this is a
breaking ABI change? Meaning that it's not possible to compile a binary that
will work on both FreeBSD systems before the change and FreeBSD systems after
it?

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

--- Comment #1 from Cy Schubert  ---
Silly me, thinking kernel instead of application. s/panic/segfault/.

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17596

Cy Schubert  changed:

   What|Removed |Added

   Priority|P1  |P2

--