[Issue 16017] package functions show up in std.experimental.allocator.common docs

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

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

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

https://github.com/dlang/phobos/commit/639c07e9428df844bb21adb8007503aa1e33b9b2
Fix Issue 16017 - package functions show up in
std.experimental.allocator.common docs

https://github.com/dlang/phobos/commit/d10a9da36b273c57308b52b92ca7a6aefe9b37f0
Merge pull request #6005 from wilzbach/fix-16017

--

[Issue 17440] Nullable.nullify() resets referenced object

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

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

--- Comment #12 from hst...@quickfur.ath.cx ---
I think you misunderstood my comment.  I meant that one way to fix this bug is
to change Nullable, or at least the overload that takes a single type
parameter, so that it does not instantiate for reference types, or redirects
the instantiation to Nullable!(T, null), so that when you call .nullify on it,
it will just set the reference to null instead of attempting to destroy the
object by calling .destroy on it.

It really does not make sense to use Nullable!T, as currently implemented, for
a class type T, since making that means there will be *two* null states, one
with .nullify / .isNull, and the other with `= null` and `is null`, and the two
null states will not be equivalent. That will only lead to more confusion.  The
fact that Nullable!T's dtor calls .destroy is further proof that the original
intent was to use it with by-value types, not with class references.  I'd say
either the docs should recommend using Nullable!(T, null) for class types T, or
else Nullable!T in that case should just internally redirect to Nullable!(T,
null).

--

[Issue 18193] module config is in file 'rt/config.d' which cannot be read

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

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

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

https://github.com/dlang/druntime/commit/10afa6944bb3ac479cbcabc5499a86136907b95f
Fix issue 18193 - module config is in file 'rt/config.d' which cannot be read
(edit)

https://github.com/dlang/druntime/commit/105d4a5ca279316665b3b796bf5ca7d249595caf
Add test to the bug 18193

--

[Issue 13742] undefined reference to __coverage

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

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

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

https://github.com/dlang/dmd/commit/69e7bd18892df18f682906916bf8c8ad87fb30e5
fix Issue 13742 - undefined reference to __coverage

- Nested template functions may reference coverage symbols of other modules.
  Those coverage symbols are either still `null` or already `symbol_reset`, in
  the former case coverage instrumentation is silently skipped, in the later
  case the linker will cause an error. This is because the current object file
  ends up with two `__coverage` symbols, one local BSS symbols and an undefined
  external symbol (for the other module's coverage).

- Fixed by mangling the symbols as _D3pkg3mod__coverageZ (similar to
  __ModuleInfoZ) and making them global.

- Ideally the symbols would use -visibility=hidden, but that ELF backend
feature
  isn't yet accessible from glue.d.

- This does not fix missing coverage when the referenced module hasn't yet
  been codegen'ed (e.g. because it follows on the command line or is part of
  another separate compilation). Using weak linkage to make this heuristically
  work would incurr some overhead for the coverage instrumentation.
  Unconditionally referencing coverage info OTOH might be too excessive,
  e.g. when the template function is in phobos, which would require to
recompile
  phobos with -cov for successful linking.

https://github.com/dlang/dmd/commit/0cb16110c307b608034d49289e2a650e7d7d7dd8
Merge pull request #7654 from MartinNowak/fix13742

fix Issue 13742 - undefined reference to __coverage

--

[Issue 13742] undefined reference to __coverage

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

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

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

--

[Issue 18233] building with -m64 doesn't work with sc.ini from the zip distribution and VS2017

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

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

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

https://github.com/dlang/dmd/commit/e9b2864e1b0f59415045533423c64447b3e468aa
fix issue 18233 - building with -m64 doesn't work with sc.ini from the zip
distribution and VS2017

https://github.com/dlang/dmd/commit/a81d286dd69dafb6d8c2605804602b19e98634dd
Merge pull request #7686 from rainers/cleanup_ini

--

[Issue 18111] unittests get different names depending on how the files are passed to dmd

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

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

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

https://github.com/dlang/dmd/commit/3b551d3ce6d9d654ba64c11ce0c7c926b1197aa0
Fix issue 18111: use fully qualified name for modules in unittest names

https://github.com/dlang/dmd/commit/e6038789f09d629bc2401569be88689dee665e3f
Merge pull request #7496 from atilaneves/fix_issue_18111

--

[Issue 17440] Nullable.nullify() resets referenced object

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

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

--- Comment #11 from Marenz  ---
I can only repeat what I said before. The principle of the least surprise
should apply. No one expects their object to be destroyed when a reference to
it is set to null, be it through .nullify(); or through = null;
It's not difficult to fix and it saves lots of people debugging time, figuring
out why the hell their object is gone.

Note that already two persons have stumbled over this AND have reported it. God
knows how many more this happened to who haven't given this valuable feedback.

--

[Issue 18242] DMD Segmentation fault.

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

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

--- Comment #1 from changlon  ---


/**
 * This code is based on Adam D. Ruppe $(LINK2
http://arsdnet.net/dcode/minimal.zip minimal.zip).
 * Probably Boost licensed
 */
module object;


/// All D class objects inherit from Object.
class Object {
}

/// The base class of all thrown objects.
class Throwable {

}


int _d_run_main() {
int result = void;
try result = 1;
catch(Throwable e) _d_print_throwable;
}


==
dmd -defaultlib= -debuglib=  object.d

--

[Issue 18242] New: DMD Segmentation fault.

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

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

  Issue ID: 18242
   Summary: DMD Segmentation fault.
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: chang...@gmail.com

I run into DMD segmentation fault under linux and Mac OSX, not test windows
yet.


DMD v2.078.0-401-g716303a41-dirty DEBUG

Program received signal SIGSEGV, Segmentation fault.
0x558c694e in
_D3dmd12statementsem13catchSemanticFCQBj9statement5CatchPSQCe6dscope5ScopeZv
(sc=0x75f611e0, 
c=0x77efb550) at dmd/statementsem.d:4038
4038 cd != ClassDeclaration.exception &&
!ClassDeclaration.exception.isBaseOf(cd, null) &&


The demangle symbol is: void
dmd.statementsem.catchSemantic(dmd.statement.Catch, dmd.dscope.Scope*) 


The code is rather big and I can not made it work with dustmite.

--

[Issue 18241] Missing characters from std.uni.unicode.Default_Ignorable_Code_Point

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

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from hst...@quickfur.ath.cx ---
Actually, nevermind this bug. The file at
http://www.unicode.org/L2/L2002/02368-default-ignorable.pdf is outdated;
std.uni actually does obey the latest standard as given in
ftp://ftp.unicode.org/Public/UNIDATA/DerivedCoreProperties.txt.

--

[Issue 18241] Missing characters from std.uni.unicode.Default_Ignorable_Code_Point

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

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

--- Comment #1 from hst...@quickfur.ath.cx ---
Actually, strike U+06DD and U+070F from the list. These are explicitly
specified by TR 44 as being exceptional cases that should NOT be ignored, even
though they belong to the Cf category.

--

[Issue 18241] New: Missing characters from std.uni.unicode.Default_Ignorable_Code_Point

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

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

  Issue ID: 18241
   Summary: Missing characters from
std.uni.unicode.Default_Ignorable_Code_Point
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

The set returned by unicode.Default_Ignorable_Code_Point is missing some
characters listed in:

http://www.unicode.org/L2/L2002/02368-default-ignorable.pdf

where Default_Ignorable_Code_Point is defined as:

Other_Default_Ignorable_Code_Point + (Cf + Cc + Cs - White_Space)

While characters in Other_Default_Ignorable_Code_Point seem to be included
correctly, two characters in Cf appear to be missing from the set:

- U+06DD
- U+070F

Furthermore, characters in (Cc - White_Space) are also missing:

- U+ to U+0008
- U+000E to U+001F


(See also: PR #5, referencing the Unicode Standard section 5.22.)


Not sure if this is because these missing characters were added in a later
Unicode standard than was originally implemented in std.uni.

--

[Issue 18240] core.stdc.wchar_ wmemset, etc. should be pure

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

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

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

https://github.com/dlang/druntime/commit/2bc68a917905faa89eb9b6458dc52b0cdf992ea4
Fix Issue 18240 - core.stdc.wchar_ wmemset, etc. should be pure

Also regularize qualifiers to match core.stdc.string.

https://github.com/dlang/druntime/commit/c5b2777dd05b676c001677a808a60d352d43e6a2
Merge pull request #2043 from n8sh/wmemset-pure

Fix Issue 18240 - core.stdc.wchar_ wmemset, etc. should be pure
merged-on-behalf-of: Iain Buclaw 

--

[Issue 17440] Nullable.nullify() resets referenced object

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

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

--- Comment #10 from hst...@quickfur.ath.cx ---
P.S. Actually, Nullable does have another overload that takes a null value to
be used in lieu of a boolean flag.  So conceivably, you could use Nullable!(T,
null) instead of Nullable!T and you will have the requisite semantics.

--

[Issue 17440] Nullable.nullify() resets referenced object

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

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--- Comment #9 from hst...@quickfur.ath.cx ---
But by-reference objects in D *already* have nullable semantics, i.e.:

---
class C {}
C c;
assert(c is null); // c is null by default
c = new C;
assert(c !is null);
c = null; // nullify
assert(c is null);
---

Of course the syntax is slightly different (direct use of null vs. .isNull /
.nullify).  But there's really no benefit to using Nullable with reference
types in D.

OTOH, if you're using generic code that expect a single API for nullable
objects, perhaps the solution is to write an overload of Nullable that simply
maps .isNull to `is null` and .nullify to `= null` when the wrapped type is a
class.

--

[Issue 17462] Order of base interfaces affects compiler behavior

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

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

--- Comment #4 from Andrei Alexandrescu  ---
The following C++ equivalent does require the additional implementation
(uncomment code to get it to compile):


class Marker {};
class Foo { public: virtual void foo() = 0; };

class FooMarked : public Foo, public Marker {};
class MarkedFoo : public Marker, public Foo  {};

class Base : public Foo { virtual void foo() {} };

class Derived1 : public Base, public FooMarked {
//virtual void foo() {}
}; 
class Derived2 : public Base, public MarkedFoo {
//virtual void foo() {}
};

int main() {
auto d1 = new Derived1;
auto d2 = new Derived2;
}


However, this other code, which arguably is closer in spirit, does work:


class Marker {};
class Foo { public: virtual void foo() = 0; };

class FooMarked : virtual public Foo, public Marker {};
class MarkedFoo : public Marker, virtual public Foo  {};

class Base : virtual public Foo { virtual void foo() {} };

class Derived1 : public Base, public FooMarked {}; 
class Derived2 : public Base, public MarkedFoo {};

int main() {
auto d1 = new Derived1;
auto d2 = new Derived2;
}


--

[Issue 17462] Order of base interfaces affects compiler behavior

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

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

Rainer Schuetze  changed:

   What|Removed |Added

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

--- Comment #3 from Rainer Schuetze  ---
I always considered it a great relief that you don't have to reimplement common
interfaces. Otherwise COM-programming would be much more verbose. What's the
reasoning to disallow it?

The old samples in dmd/samples also assume that IUnknown doesn't have to be
reimplemented.

--

[Issue 17462] Order of base interfaces affects compiler behavior

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

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #2 from Andrei Alexandrescu  ---
FWIW the Java code works without requiring the additional implementation:

interface Marker {}
interface Foo { void foo(); }

interface FooMarked extends Foo, Marker {}
interface MarkedFoo extends Marker, Foo  {}

class Base implements Foo { public void foo() {} }

class Derived1 extends Base implements FooMarked {} // Inherit Base.foo
class Derived2 extends Base implements MarkedFoo {} // Inherit Base.foo

--

[Issue 18240] New: core.stdc.wchar_ wmemset, etc. should be pure

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

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

  Issue ID: 18240
   Summary: core.stdc.wchar_ wmemset, etc. should be pure
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

Functions in core.stdc.wchar_ should have the same purity as the corresponding
non-wide functions in core.stc.string.

--

[Issue 18239] std.experimental.allocator fillWithMemcpy could use memset when T.sizeof==1

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

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

--- Comment #2 from Nathan S.  ---
(In reply to Nathan S. from comment #1)
> Could also use wmemset when T.sizeof == wint_t.sizeof

Unfortunately core.stdc.wchar_.wmemset isn't marked as pure so this would cause
some tests to fail.

--

[Issue 18239] std.experimental.allocator fillWithMemcpy could use memset when T.sizeof==1

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

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

Nathan S.  changed:

   What|Removed |Added

Summary|std.experimental.allocator  |std.experimental.allocator
   |fillWithMemcpy could use|fillWithMemcpy could use
   |memset/wmemset for  |memset when T.sizeof==1
   |T.sizeof==1 or  |
   |wint_t.sizeof   |

--

[Issue 18239] std.experimental.allocator fillWithMemcpy could use memset/wmemset for T.sizeof==1 or wint_t.sizeof

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

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

--- Comment #1 from Nathan S.  ---
Could also use wmemset when T.sizeof == wint_t.sizeof

--

[Issue 18239] std.experimental.allocator fillWithMemcpy could use memset/wmemset for T.sizeof==1 or wint_t.sizeof

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

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

Nathan S.  changed:

   What|Removed |Added

Summary|std.experimental.allocator  |std.experimental.allocator
   |fillWithMemcpy could use|fillWithMemcpy could use
   |memset when T.sizeof==1 |memset/wmemset for
   ||T.sizeof==1 or
   ||wint_t.sizeof

--

[Issue 18239] New: std.experimental.allocator fillWithMemcpy could use memset when T.sizeof==1

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

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

  Issue ID: 18239
   Summary: std.experimental.allocator fillWithMemcpy could use
memset when T.sizeof==1
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

Current function in std.experimental.allocator.package:
```
private void fillWithMemcpy(T)(void[] array, auto ref T filler) nothrow
{
import core.stdc.string : memcpy;
import std.algorithm.comparison : min;
if (!array.length) return;
memcpy(array.ptr, , T.sizeof);
// Fill the array from the initialized portion of itself exponentially.
for (size_t offset = T.sizeof; offset < array.length; )
{
size_t extent = min(offset, array.length - offset);
memcpy(array.ptr + offset, array.ptr, extent);
offset += extent;
}
}
```

When T.sizeof==1 we could use memset instead.

If this change is made it might be a good idea to change the name of the
function to avoid an implicit contract that it uses the memcpy function.

--

[Issue 18230] multiwayUnion sets wrong pred lambdas

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

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #1 from RazvanN  ---
PR : https://github.com/dlang/phobos/pull/6032

--

[Issue 18068] No file names and line numbers in stack trace

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

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

--- Comment #5 from Seb  ---
test/runnable/test17559.d in the DMD testsuite fails too.

--