[Issue 15376] New: The time zone name conversions should not be compiled into Phobos

[via Digitalmars-d-bugs]

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

  Issue ID: 15376
   Summary: The time zone name conversions should not be compiled
into Phobos
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: issues.dl...@jmdavisprog.com

As it stands, every time that Microsoft changes the list of time zones that
they have, tzDatabaseNameToWindowsTZName and windowsTZNameToTZDatabaseName in
std.datetime have to be updated, and it's proven to be a maintenance problem
(not to mention that it means that older releases won't work properly with
Windows machines that have been properly updated). So, we should introduce a
way to get those conversions at runtime rather than compile time (presumably by
reading in the windowsZones.xml file that the conversions come from in the
first place) and then deprecate tzDatabaseNameToWindowsTZName,
windowsTZNameToTZDatabaseName, and TimeZone.getTimeZone.

--

[Issue 15376] The time zone name conversions should not be compiled into Phobos

[via Digitalmars-d-bugs]

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

--- Comment #1 from Jonathan M Davis  ---
https://github.com/D-Programming-Language/phobos/pull/3824

--

[Issue 15284] dmd installer hangs when updating installed windows version

[via Digitalmars-d-bugs]

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

--- Comment #20 from Martin Nowak  ---
(In reply to Martin Nowak from comment #11)
> From Thomas Mader:
> http://forum.dlang.org/post/gjdwctcoakpfxzyjd...@forum.dlang.org
>

@Martin: In reply to
https://issues.dlang.org/show_bug.cgi?id=15284#c11.

I switched the installers for my workplace from NSIS to InnoSetup
[1] and was very satisfied with it.
In my opinion it's superior to NSIS.
It might be worthwile to strive to change but I might be wrong
because I never looked on the Dlang installers.

[1] http://www.jrsoftware.org/isinfo.php

--

[Issue 15372] New: DMD emits wrong mangling for extern(C++) free function templates

[via Digitalmars-d-bugs]

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

  Issue ID: 15372
   Summary: DMD emits wrong mangling for extern(C++) free function
templates
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: jakobov...@gmail.com

cppsrc/interop.cpp:

template
void foo()
{
}

void test()
{
foo();
}


dsrc/interop.d:

extern(C++) void foo(T)();

void main()
{
foo!int();
}


Built with:

g++ -c cppsrc/interop.cpp --output=cpp_interop.o
dmd dsrc/interop.d cpp_interop.o


Output:

interop.o: In function `_Dmain':
dsrc/interop.d:(.text._Dmain+0x5): undefined reference to `foo::foo()'
collect2: error: ld returned 1 exit status
--- errorlevel 1


nm --demangle cpp_interop.o:

 W void foo()
 T test()


nm --demangle interop.o:

 ...
 U foo::foo()
 ...


nm cpp_interop.o:

 W _Z3fooIiEvv
 T _Z4testv


nm interop.o:

 ...
 U _ZN3fooIiE3fooEv
 ...


Using g++ (GCC) 5.2.0 and DMD git head on Linux. Passing --std=c++11 when
compiling the C++ code results in the same mangled names. Using -L-lstdc++ is
of course not relevant here either.

This is an issue for
https://github.com/D-Programming-Language/dlang.org/pull/1154

--

[Issue 15373] New: Segfault when using typeid on extern(C++) class with virtual functions

[via Digitalmars-d-bugs]

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

  Issue ID: 15373
   Summary: Segfault when using typeid on extern(C++) class with
virtual functions
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: jakobov...@gmail.com


extern(C++) interface I
{
void foo();
}

extern(C++) class C : I
{
override void foo() {}
}

void main()
{
import std.stdio;
writeln(typeid(new C)); // segfault
}


This seems like it should be statically disallowed. Any type with an
extern(C++) type in its inheritance hierarchy should be disallowed in typeid().
I don't know if extern(C++) classes can implement D interfaces, but it should
at least return null in such cases.

--

[Issue 15374] [internal] Nothing should import ddmd.mars

[via Digitalmars-d-bugs]

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

David Nadlinger  changed:

   What|Removed |Added

 CC||c...@klickverbot.at

--- Comment #1 from David Nadlinger  ---
Yep, we (LDC) define our own main() too.

--

[Issue 3468] dmd allows negative values to be assigned to an uint variable

[via Digitalmars-d-bugs]

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

Mathias LANG  changed:

   What|Removed |Added

 CC||pro.mathias.l...@gmail.com
Version|D1 (retired)|D2
 OS|Linux   |All

--- Comment #2 from Mathias LANG  ---
This 'bug' is still around in D2.
It looks like an heritage from C / C++, one of the bad kind.

It allows you to write gems such as:
```
uint func (int i) { return i; }

void main ()
{
  uint v = func(-42);
}
```

@Walter: Would you be okay with the idea of deprecating this ?
Related: https://issues.dlang.org/show_bug.cgi?id=259

--

[Issue 15365] std.math: 80-bit exp() tests are utterly wrong when returning subnormals

[via Digitalmars-d-bugs]

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

--- Comment #3 from Iain Buclaw  ---
Stepped through the path dmd code uses for exp().

(1) 0x1.1p13L   - Uses L_normal path
(2) -0x1.18p+13L- Uses L_normal path
(3) -0x1.625p+13L   - Uses L_normal path
(4) -0x1.62dafp+13L - Uses L_normal path

Interestingly, the last test exp(-11398) uses the L_subnormal path, and returns
results that are correct to wolfram in at least the bits that can be
represented.

Also tried exp(-11370) and exp(-11387.4), and on the surface it looks like any
near underflow/subnormal that represents a decimal will only be correct up to
double precision.

Also tested the first iteration of exp() and it returns the same results.

--

[Issue 15374] New: [internal] Nothing should import ddmd.mars

[via Digitalmars-d-bugs]

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

  Issue ID: 15374
   Summary: [internal] Nothing should import ddmd.mars
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ibuc...@gdcproject.org

These modules all import ddmd.mars.

ddmd.attrib
ddmd.cond
ddmd.dimport
ddmd.doc
ddmd.expression
ddmd.func
ddmd.hdrgen

Because these four functions are defined there:

readFile
writeFile
ensurePathToNameExists
escapePath


As ddmd.mars is the main function, nothing should be importing it.  These
helper/utility functions should either be moved elsewhere or put in it's own
module.

This is a foreseeable blocker for switching to the new D frontend, as the main
function is defined elsewhere in GDC, possibly LDC too?

--

[Issue 15374] [internal] Nothing should import ddmd.mars

[via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

 CC||ibuc...@gdcproject.org

--- Comment #2 from Iain Buclaw  ---
Thanks for clarifying,

Raised PR here.  Feel free to direct your opinion on how things should be
handled.

https://github.com/D-Programming-Language/dmd/pull/5282

--