[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 17625] Confusing error message for private functions in different modules

[via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 17625] New: Confusing error message for private functions in different modules

[via Digitalmars-d-bugs]

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

  Issue ID: 17625
   Summary: Confusing error message for private functions in
different modules
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: trivial
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ket...@ketmar.no-ip.org

i don't know how to make a clear summary for this, sorry. anyway, here is the
code. let's create three modules:

=== z00.d ===
module z00;
private int boo () { return 42; }

=== z01.d ===
module z01;
private int boo () { return 69; }

=== zmain.d ===
module zmain;
import z00, z01;
void main () { boo(); }


now, do:
dmd -c -o- zmain.d z00.d z01.d

and you'll get:
zmain.d(3): Error: z01.boo at z01.d(2) conflicts with z00.boo at z00.d(2)
zmain.d(3): Error: function z01.boo is not accessible from module zmain

while the second error message gives at least *some* information, the first one
is not only completely useless, but is misleading too: user may think that he
has to rename one of the private functions to get rid of it.

i think that compiler should just say "undefined identifier `boo`", 'cause
visibility rules mandates that private functions are not visible at that point,
and there is no sense in trying to resolve anything there.

--

[Issue 16650] Wrong mangling for extern(C++) with posix stat_t

[via Digitalmars-d-bugs]

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

--- Comment #4 from Vladimir Panteleev  ---
It's easy enough to test!

$ cat test.d 
pragma(mangle, "CeciNestPasUnS")
struct S { }

extern(C++) void fun(S* s);

pragma(msg, fun.mangleof);

$ dmd -o- test.d
_Z3funP1S

Looks like pragma(mangle) has no effect on structs so far.

--

[Issue 17624] New: typo in Fields documentation section of https://dlang.org/library/object/exception.html

[via Digitalmars-d-bugs]

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

  Issue ID: 17624
   Summary: typo in Fields documentation section of
https://dlang.org/library/object/exception.html
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: trivial
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: khea...@gmail.com

In the Fields section of https://dlang.org/library/object/exception.html

it says:

file string - The file name and line number of the D source code corresponding
with where the error was thrown from.
...
line ulong  - The file name and line number of the D source code corresponding
with where the error was thrown from.



Believe it should say:

file string - The file name of the D source code corresponding with where the
error was thrown from.
...
line ulong  - The line number of the D source code corresponding with where the
error was thrown from.

--

[Issue 9776] Make raw write mode the default

[via Digitalmars-d-bugs]

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

--- Comment #10 from Nick Sabalausky  ---
As already said before, windows notepad is the *only program that doesn't
handle it (which makes it very *unlike* '/' if indeed "many programs" fail to
deal with properly - which is an exaggeration anyway, but that's beside the
point). If I'm wrong and \n is indeed poorly supported on Windows, then it
should be a simple matter to go ahead and name other examples.

Contrast that to the "\r\r\n" that D code is demonstrably prone to emitting on
Windows, which is handled correctly by little, if anything, on any OS. The
safer behavior is clear, and the consensus of the discussion was the same.

Stubborn clingage to false information and misplaced fears is not befitting of
D.

--

[Issue 17004] std.containers should be usable with @nogc

[via Digitalmars-d-bugs]

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
This is WIP.
See also: http://dconf.org/2017/talks/staniloiu.html

--

[Issue 6410] Few common exceptions in std.exception

[via Digitalmars-d-bugs]

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

--- Comment #6 from Jonathan M Davis  ---
(In reply to greenify from comment #5)
> FYI there will be HttpStatusException soon:
> https://github.com/dlang/phobos/pull/5551

Yeah, but it's not generic. It's derived from std.net.curl.CurlException and
really only makes sense for std.net.curl. It's not something that another
library like vibe.d would use.

--

[Issue 16650] Wrong mangling for extern(C++) with posix stat_t

[via Digitalmars-d-bugs]

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

--- Comment #3 from Jacob Carlborg  ---
Is it possible to use pragman(mangle) on a struct?

--

[Issue 16856] D does not work on FreeBSD current (what will eventually be 12) due to libunwind

[via Digitalmars-d-bugs]

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

--- Comment #11 from Nemanja Boric <4bur...@gmail.com> ---
https://github.com/dlang/druntime/pull/1862

--

[Issue 9776] Make raw write mode the default

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #9 from Walter Bright  ---
> unnecessary on all versions of windows

Windows Notepad fails with it.

It's similar to the \ path separator problem on Windows. Many programs,
including lots of Microsoft programs, fail to deal with / properly.

--

[Issue 16397] missing coverage from template instances when using separate compilation

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/1f7e59980539fe0f9ba352b258e8266db6bdff01
fix test coverage

- use single tests as workaround for Issue 16397
- fix single tests (broken sed command)

--

[Issue 17623] Unexpected failure of an assertion on empty strings

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||spec
  Component|dmd |dlang.org
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #1 from Vladimir Panteleev  ---
This is a documentation bug; the code is correct.

A dynamic array in D is represented as a pointer (.ptr) and a length (.length).

>   string s = null;

s.length is 0 and s.ptr is null.

>   string t = "";

t.length is also 0, but t.ptr points towards a zero-length string literal. The
distinction is mainly that D string literals are zero-terminated, so that they
can be implicitly converted to a C string (const char*).

--

[Issue 17622] inline for m64 fails web APPS

[via Digitalmars-d-bugs]

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

--- Comment #2 from Vladimir Panteleev  ---
Please provide a full self-contained test case, so that we can reproduce the
bug.

--

[Issue 16397] missing coverage from template instances when using separate compilation

[via Digitalmars-d-bugs]

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

--- Comment #2 from Martin Nowak  ---
cat > a.d << CODE
module a;
import b;

unittest
{
foo!int();
}
CODE

cat > b.d << CODE
module b;

void foo(T)()
{
return; // line is covered
}

unittest
{
foo!int();
}
CODE

dmd -c -cov -unittest a.d
dmd -c -cov -unittest b.d
dmd -main a.o b.o -ofbug
./bug

cat a.lst b.lst

   |module a;
   |import b;
   |
   |unittest
   |{
  1|foo!int();
   |}
a.d is 100% covered
   |module b;
   |
   |void foo(T)()
   |{
000|return; // line is covered
   |}
   |
   |unittest
   |{
  1|foo!int();
   |}
b.d is 50% covered


With different linker order, both calls use the foo instantiation with coverage
instrumentation.

dmd -main b.o a.o -ofbug
./bug

cat a.lst b.lst

   |module a;
   |import b;
   |
   |unittest
   |{
  1|foo!int();
   |}
a.d is 100% covered
   |module b;
   |
   |void foo(T)()
   |{
  2|return; // line is covered
   |}
   |
   |unittest
   |{
  1|foo!int();
   |}
b.d is 100% covered
➜  D cat a.lst b.lst   
 20:18:21
   |module a;
   |import b;
   |
   |unittest
   |{
  1|foo!int();
   |}
a.d is 100% covered
   |module b;
   |
   |void foo(T)()
   |{
  2|return; // line is covered
   |}
   |
   |unittest
   |{
  1|foo!int();
   |}
b.d is 100% covered


--

[Issue 16856] D does not work on FreeBSD current (what will eventually be 12) due to libunwind

[via Digitalmars-d-bugs]

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

--- Comment #10 from Nemanja Boric <4bur...@gmail.com> ---
Ok, I finally got some time to get back to this issue.

There's a sigbus really running, but this is caused by GC, because the runtime
asserts in the shared library finalizers, so it seems that the instance is no
longer there.

I've traced the failing druntime assert (so far, who knows
what else is waiting for us) to this particular commit in rtld.c:

https://github.com/freebsd/freebsd/commit/3ff2e66ecba2094f5c1c1efe7f2d009649527195

So, this is the problem. At the end of the program, fini()s are called for the
shared library and the main executable. Then they call `_do_global_dtors_aux`,
and at that point they will call _d_dso_registry, which will (the problem is
here:) call dlopen (albeit with RTLD_NOLOAD) to obtain the handle for the
object by name.

However, since this particular commit, this doesn't work anymore (and it's
questionable if it should work) - you can't bump a reference count of an object
that's just going to die (dlopen still bumps reference count, even with
RTLD_LOAD passed).

I would guess somehow skipping dlopen calls in this scenario should be figured
out.
Maybe skipping just for the current object, or maybe caching the handles when
first obtained (not sure if they can change on their own; I don't think so, but
still). I'll see to submit a PR tomorrow, now I know where the problem is.

It was quite a ride finding this out. Because first call to dlopen was failing
for the
main executable, so documentation says: "use NULL if you want the main
executable instead", so after doing this - I got it working, so I thought
there's something
special with this path. What's interesting is that my confusion is caused by
the bug
in FreeBSD's code - if the current limitation apply - don't reference "doomed"
object,
one shouldn't be able to work around it by passing NULL. I'll see into sending
a patch there as well.

--

[Issue 5077] std.algorithm.schwartzSort is slow

[via Digitalmars-d-bugs]

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

safety0ff.bugz  changed:

   What|Removed |Added

 CC||safety0ff.b...@gmail.com

--- Comment #7 from safety0ff.bugz  ---
(In reply to Vladimir Panteleev from comment #6)
> Still reproducible in 2017.
> 
> FWIW, with LDC, the difference is smaller: only schwartzSort is slower than
> regular sort only by about one third rather than being about twice as slow.

Sounds like typical poor performance of using DMD with ranges (i.e.
std.range.zip used by schwartzSwort.)

Possible duplicate of: #14943 & #16120

Aside: Stripping out dynamic stopping policies from std.range.zip led to a few
% improvement on LDC, nothing big though.

--

[Issue 16397] missing coverage from template instances when using separate compilation

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

Summary|test_runner in coverage |missing coverage from
   |mode doesn't match with |template instances when
   |individual test (covers |using separate compilation
   |less)   |

--

[Issue 16397] test_runner in coverage mode doesn't match with individual test (covers less)

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #1 from Martin Nowak  ---
Turns out to be a rather trivial but inherent problem of how coverage and
linkers work.
If a template methods is instantiated in two separately compiled modules (say
std.digest.crc and std.digest.digest) the definition from the first object in
the linker argument order is picked.
Here we have our problem std.digest.digest instantiates WrapperDigest!CRC which
gets emitted with coverage information, but std.digest.crc also instantiates
WrapperDigest!CRC without coverage information (since it's in a foreign module)
the one that gets picked is the latter.

Just like with any other template behavior and -unittest I think dmd should
always emit coverage instrumentation, even if it's for functions in foreign
modules, since eventually any instance might get picked.
This requires to mangle __bcoverage and __coverage and make them linkable from
other modules, at the moment they are private symbols, only accessible from
within a single object file.

The logic that prevents increments of "foreign" modules is here in dmd.
https://github.com/dlang/dmd/blob/ce96c01d271f914cd9acb6100f7fa9f4d494ee8c/src/ddmd/toir.d#L67

--

[Issue 17621] Don't use deprecated stuff inside Phobos (std/uri.d(338): std.utf.toUTF8) or don't warn the users who are not using it.

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from Vladimir Panteleev  ---
This has already been fixed:
https://github.com/dlang/phobos/pull/5409

The fix should be included with 2.075.0.

--

[Issue 17556] std.json encodes non-BMP characters incorrectly with JSONOptions.escapeNonAsciiChars

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/941e2936b6c90fce0b11eada9605c231ca498e9f
Fix Issue 17556 - std.json encodes non-BMP characters incorrectly with
JSONOptions.escapeNonAsciiChars

--

[Issue 5904] std.json parseString doesn't handle chars outside the BMP

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/b23e7a4107cc2eb3275e022cb46f7270e586ca29
Fix Issue 5904 - std.json parseString doesn't handle chars outside the BMP

--

[Issue 17555] [REG2.070.0] Control characters in JSON data are invalid and should cause an exception

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/55aa34e4407cd24a29f5e271a3fa318d56acf487
Fix Issue 17555 - [REG2.070.0] Control characters in JSON data are invalid and
should cause an exception

--

[Issue 17623] New: Unexpected failure of an assertion on empty strings

[via Digitalmars-d-bugs]

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

  Issue ID: 17623
   Summary: Unexpected failure of an assertion on empty strings
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: kde...@vogtner.de

According to the documentation [1]:

   "For static and dynamic arrays, identity is defined as referring to
the same array elements and the same number of elements."

this code

   $ cat stringidentity.d 
   void main ()
   {
  string s = null;
  string t = "";
  assert (s is t);
   }

shall pass but the assertion fails

   $ ./stringidentity
   core.exception.AssertError@stringidentity.d(5): Assertion failure

[1] https://dlang.org/spec/expression.html#identity_expressions

--

[Issue 17564] std.experimental.allocator.theAllocator is null within shared static this

[via Digitalmars-d-bugs]

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/4a5d2b3b189f072e9bd0b1779a7d585e3945921b
Fix issue 17564: Eliminate "static this" for theAllocator

https://github.com/dlang/phobos/commit/2e0a49cd397ea1bdb993e3a9271193cf6051b8ce
Merge pull request #5519 from s-ludwig/lazy_the_allocator

--

[Issue 17557] std.json should not do UTF decoding when parsing

[via Digitalmars-d-bugs]

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/226f8e001c256836bdcc7917443704db93f318c3
Fix Issue 17557 - std.json should not do UTF decoding when parsing

--

[Issue 17553] std.json should not do UTF decoding when encoding JSON

[via Digitalmars-d-bugs]

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/5031ff1446f58a4a76e16d76aa80329d1981cb32
Fix Issue 17553 - std.json should not do UTF decoding when encoding JSON

--

[Issue 17622] inline for m64 fails web APPS

[via Digitalmars-d-bugs]

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

steven kladitis  changed:

   What|Removed |Added

   Keywords||dll

--- Comment #1 from steven kladitis  ---
when using -inline in 64 bit mode all apps I have the goto the web do not work.
-m64 -inline 
on windows 10 64 bit
Windows comes back with a message about debugging the app.
Without -inline they work.

compiler --> DMD32 D Compiler 2.075.0-b2

--

[Issue 17622] New: inline for m64 fails web APPS

[via Digitalmars-d-bugs]

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

  Issue ID: 17622
   Summary: inline  for m64 fails web APPS
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: steven_kladi...@yahoo.com

--

[Issue 17621] New: Don't use deprecated stuff inside Phobos (std/uri.d(338): std.utf.toUTF8) or don't warn the users who are not using it.

[via Digitalmars-d-bugs]

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

  Issue ID: 17621
   Summary: Don't use deprecated stuff inside Phobos
(std/uri.d(338): std.utf.toUTF8) or don't warn the
users who are not using it.
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: kde...@vogtner.de

$ cat toutf8warning.d
void main ()
{
   import std.uri;
   "".decodeComponent;
}
$ dmd toutf8warning 
[redacted]/dmd2/linux/bin64/../../src/phobos/std/uri.d(338): Deprecation:
function std.utf.toUTF8 is deprecated - To be removed November 2017. Please use
std.utf.encode instead.
$ dmd --version
DMD64 D Compiler v2.074.1
Copyright (c) 1999-2017 by Digital Mars written by Walter Bright

--

[Issue 7063] No error or warning for conflicting D and C symbols

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||accepts-invalid
   Hardware|x86 |All

--

[Issue 17620] dwarfeh(327) fatal error

[via Digitalmars-d-bugs]

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

Sönke Ludwig  changed:

   What|Removed |Added

 CC||slud...@outerproduct.org

--- Comment #1 from Sönke Ludwig  ---
Small correction: It happens in the vibe.d based reverse proxy that sits in
front of the registry process.

It seems to happen occasionally when the SSL stream throws an exception due to
some protocol error (this is the only exception that happens during normal
operation). I will try again to prepare a test case, although that has proven
difficult in the past.

--

[Issue 16641] Infinite loop on InvalidMemoryOperationError in __dmd_personality_v0

[via Digitalmars-d-bugs]

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

--- Comment #4 from Etienne  ---
I still get this infinite loop problem every now and then. I got around it by
auto-launching more processes and killing them every hour, it seems like it
happens when my (very busy) application starts to throw more frequently. It
became 99% less frequent after putting a loop counter in this code

auto eh = ExceptionHeader.toExceptionHeader(exceptionObject);
int infini_guard;
while (eh.next && ++infini_guard < 1)
{
ExceptionHeader* ehn = eh.next;

--

[Issue 6410] Few common exceptions in std.exception

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #5 from greenify  ---
FYI there will be HttpStatusException soon:
https://github.com/dlang/phobos/pull/5551

--

[Issue 16641] Infinite loop on InvalidMemoryOperationError in __dmd_personality_v0

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

   Keywords||EH
 CC||c...@dawg.eu

--- Comment #3 from Martin Nowak  ---
We got a similar report for dub-registry (not using botan I assume).

--

[Issue 17620] New: dwarfeh(327) fatal error

[via Digitalmars-d-bugs]

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

  Issue ID: 17620
   Summary: dwarfeh(327) fatal error
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Keywords: EH
  Severity: major
  Priority: P3
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

We have reports that dub-registry as of it's current version [¹] is constantly
crashing with "dwarfeh(327) fatal error". Occasionally it hangs in a busy loop
which sounds like a duplicate of issue 16641.

[¹]:
https://github.com/dlang/dub-registry/commit/e7c1868566888e6b29f570cb5731b9bf56e790c9
[²]:
https://github.com/dlang/druntime/blob/0d1fa213b492ef2e236769e4fd634ba9d38b4fc1/src/rt/dwarfeh.d#L327

--

[Issue 17271] dwarfeh(224) fatal error

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

   Keywords||EH
   Priority|P1  |P3
   Hardware|x86 |All
   Severity|enhancement |major

--

[Issue 17271] dwarfeh(224) fatal error

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu
 OS|Windows |All

--- Comment #2 from Martin Nowak  ---
Might have been affected by https://github.com/dlang/druntime/pull/1673, at
least what previously was an error should now print the exception before
terminating.
Could you please recheck

--

[Issue 6410] Few common exceptions in std.exception

[via Digitalmars-d-bugs]

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

--- Comment #4 from Vladimir Panteleev  ---
I think the only good idea from bearophile's list is OverflowException, as
conversion data often comes from user input, and it may be useful to
distinguish values that are syntactically correct but simply too large to be
represented in the program's chosen data type, from values that are
syntactically incorrect.

--

[Issue 17619] [REG2.072] Wrong debug line information with single line loops

[via Digitalmars-d-bugs]

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

--- Comment #2 from Martin Krejcirik  ---
(In reply to Rainer Schuetze from comment #1)
> 1. the line number attached to the end of the for statement is the line of
> the token following the loop, while it should be the line after the last
> token of the statement. That would not really help if the declaration of
> "bad" would not be separated by an empty line, though.

I wonder if it could just stay in the loop body if there is no closing curly
bracket. However, if I add curly brackets to the single body line, it shows
foreach line on every iteration, so for consistency, it should be the same
without curlys;


>  When breaking inside test2, the call stack will look like it is being
> called by test1();

I don't observe such behaviour with an older dmd.

--

[Issue 17619] [REG2.072] Wrong debug line information with single line loops

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #1 from Rainer Schuetze  ---
I think there are (at least) two issues here:

1. the line number attached to the end of the for statement is the line of the
token following the loop, while it should be the line after the last token of
the statement. That would not really help if the declaration of "bad" would not
be separated by an empty line, though.

2. there is no perfect fit for the line number attached to the loop iteration
and jump back to the start:

  - if it is after the loop, it looks as if the loop has already terminated (as
reported here). This also happens sometimes for C++ code with VC (not sure
about gcc).

  - if it is on the loop statement the call stack of a function call inside the
loop can get confusing, e.g.

void main()
{
test1();
foreach (i; 0 .. 3)
test2();
}

 When breaking inside test2, the call stack will look like it is being
called by test1();

--