[Issue 17060] betterC std.allocator

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--

[Issue 17060] New: betterC std.allocator

[via Digitalmars-d-bugs]

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

  Issue ID: 17060
   Summary: betterC std.allocator
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ilyayaroshe...@gmail.com

Part 1
-

std.allocator can be split (virtually) into three parts:

1. OOP Interfaces, theAllocator, constructors and other global variables.
2. Always inlined code.
3. Generic code.

1: OOP code and global variables can be placed in separate module.

2: We have `pragma(inline, true)`. Each function for non-generuc stuff like
Mallocator can be marked with this pragma. The size of code seems to be small
enough to be always inlined.

3: Generic code should be already fine.



Part 2
-
std.allocator uses some functions from `core.*` and maybe `std.*`. They should
be betterC too. I don't know how to verify it for all compilers.

--

[Issue 16595] thisExePath resolves symlinks but this isn't mentioned in docs

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16604] [std.getopt] defaultGetoptPrinter can't be used if an exception fires

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16590] Wrong di generation for ref methods

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16959] bringToFront fails on char arrays

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16686] Can not spawn subprocess and read from File at same time

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16662] Can't call std.variant.visit from a pure function

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16656] move embedded zlib to a separate library

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16630] Compile errors with std.traits.arity and std.traits.ParameterStorageClassTuple

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16564] KRRegion.empty sometimes returns Ternary.no

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16736] Retrieving cUrl time values is quite cumbersome

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16659] Clarify mutating while iterating rules

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16684] std.getopt, problem with the automatic handling of "h"

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16991] Make writeln documentation palatable

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16985] Enable runnable unittest on dlang.org after 2.073 release

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16615] std.process is missing functionality for child processes

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16984] Make more modules runnable on dlang.org

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16783] std.net.curl application throws an exception

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED

--

[Issue 16542] makeArray not usable with const initializer

[via Digitalmars-d-bugs]

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--

[Issue 16355] __xpostblit incorrectly generated for a struct with a zero-length static array

[via Digitalmars-d-bugs]

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

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #1 from bitter.ta...@gmx.com ---
Covered by DMD's PR https://github.com/dlang/dmd/pull/6400

--

[Issue 16694] ICE on taking address of `export` function (declaration-only)

[via Digitalmars-d-bugs]

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

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #1 from bitter.ta...@gmx.com ---
Covered by PR https://github.com/dlang/dmd/pull/6259

--

[Issue 17056] No filename and line info for wrong extern C++ type

[via Digitalmars-d-bugs]

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

--- Comment #4 from bitter.ta...@gmx.com ---
(In reply to Jacob Carlborg from comment #2)
> (In reply to bitter.taste from comment #1)
> > This should be only a matter of using the Loc of the Dsymbol we're currently
> > mangling when an error is thrown.
> 
> I'm pretty sure it's reporting the error as "Internal Compiler Error"
> because the error should have been caught earlier, properly reported with
> file and line number.

Nah, it's just that every error that's thrown from cppmangle.d is prefixed with
"Internal Compiler Error" and uses Loc() as loc instead of using the one of the
symbol it is trying to mangle.
No type checking is done in the mangler, it's just that there's no C++ type a D
`string' maps to, you could effectively prevent the use of types that have no
1:1 mapping to C++ ones but that's another matter, this approach just works
(TM).

--

[Issue 16048] std.getopt: duplicated options are not detected

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/43880932f56f412eb5c3e4fcc395c507c1aa93ad
Throw error on duplicate long/short options

Fixes Issue 16048

--

[Issue 17056] No filename and line info for wrong extern C++ type

[via Digitalmars-d-bugs]

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

--- Comment #3 from Jacob Carlborg  ---
The mangler shouldn't do the type checking.

--

[Issue 17056] No filename and line info for wrong extern C++ type

[via Digitalmars-d-bugs]

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

Jacob Carlborg  changed:

   What|Removed |Added

 CC||d...@me.com

--- Comment #2 from Jacob Carlborg  ---
(In reply to bitter.taste from comment #1)
> This should be only a matter of using the Loc of the Dsymbol we're currently
> mangling when an error is thrown.

I'm pretty sure it's reporting the error as "Internal Compiler Error" because
the error should have been caught earlier, properly reported with file and line
number.

--

[Issue 16191] std/digest/digest.d should be renamed to package.d

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #1 from greenify  ---
pull: https://github.com/dlang/phobos/pull/5013

--

[Issue 16298] [ER] lazily register standard codecs from std.encoding

[via Digitalmars-d-bugs]

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

--- Comment #2 from Ketmar Dark  ---
this was just a place to keep the temporary solution anyway. Steven took care
of that since, i believe. sorry, i forgot to close this myself.

and yes, i know that patches in bugzilla rots forever without any movement (and
patches published in NG are lost at the moment they put there ;-), but i am not
using github, so this is the only way i can contribute. alas.

--

[Issue 17036] Template default parametr does not works correctly

[via Digitalmars-d-bugs]

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

--- Comment #2 from Daniel Kozak  ---
yeah I am aware of all of this, but in all other cases(context) it is legal to
do this cast. It is even legal by language specification if I remember it
correctly.

I would fix it by myself but thera are many ways to fix this and i am not sure
which way is the best, so I hope someone with more skill try to fix it or
propose some solution or direction

--

[Issue 16298] [ER] lazily register standard codecs from std.encoding

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greeen...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from greenify  ---
> for the time being, until the proper fix for cycle detection in module ctors 
> isn't complete.

AFAIK the cycle detection has been fixed
(https://github.com/dlang/druntime/pull/1602), so I think this makes this issue
obsolete (please reopen if you disagree)
As you might have realized your patch got quite stalled here, so in the future
either submitting a PR or posting it to the mailing list could lead to more
success ;-)

--

[Issue 16510] Request: RSA digital signature validation in phobos

[via Digitalmars-d-bugs]

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

greenify  changed:

   What|Removed |Added

 CC||greeen...@gmail.com

--- Comment #1 from greenify  ---
There are a couple of DUB libraries that do implement RSA, e.g the botan
library: https://github.com/etcimon/botan

However it still would be nice to have it in std.digest

--

[Issue 17036] Template default parametr does not works correctly

[via Digitalmars-d-bugs]

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

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #1 from bitter.ta...@gmx.com ---
---
struct S0
{
void x[1];
}
pragma(msg, S0.init);
---

As you can see this outputs `S0([cast(ubyte)0u]`, let's assume that the
compiler is right and try using that value as initializer

---
auto x = S0([cast(ubyte)0u]; // and I thought you couldn't cast a ubyte into a
void
---

gives a fairly explicative error, which is what one would rightfully expect

---
cannot implicitly convert expression ([cast(ubyte)0u]) of type ubyte[] to
void[1]
---

on the other hand using the `.init` directly works perfectly..isn't that weird
?

---
auto x = S0.init; // works
---

Let's take a step back, where's the initializer coming from? Here it is [1],
you sneaky bastard! So what happens here is that a zero-initialized TypeSArray
is created with a void[1] type bolted on, the trick falls short when the struct
initializer (the aforementioned `S0([cast(ubyte)0u]` that now has a S0(void[1])
type) is run trough dtemplate `matchArg` and trough the CTFE engine where
nothing is done beside losing our bolted-on type.
What happens next is where the error originates, the new initializer gets
trough the semantic phase

---
ArrayLiteralExp::semantic('[cast(ubyte)0u]')
---

if you're familiar with the inner workings I'll also add that `type` is null
right now and the deduced type is `ubyte[]` which is the technically right
answer but the wrong one in this context. ugh.

Here's where the shit hits the fan

---
ArrayLiteralExp::implicitConvTo(this=[cast(ubyte)0u], type=ubyte[], t=void[1])
TypeDArray::implicitConvTo(to = void[1]) this = ubyte[]
---

What to do? One could try not to lose the hacked-up type of the array, relax
the rules for casts to `void[N]`, emit a `void` initializer instead of a
zeroing the array (which is what one would expect since void has no default
initializer), hope for the best, use another lang^Hthat's it!

[1] https://github.com/dlang/dmd/blob/master/src/mtype.d#L5040

--

[Issue 17056] No filename and line info for wrong extern C++ type

[via Digitalmars-d-bugs]

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

bitter.ta...@gmx.com changed:

   What|Removed |Added

 CC||bitter.ta...@gmx.com

--- Comment #1 from bitter.ta...@gmx.com ---
This should be only a matter of using the Loc of the Dsymbol we're currently
mangling when an error is thrown.

--