date:20170712

[Issue 17643] New: std.traits.getSymbolsByUDA doesn't work with private attributes

2017-07-12 Thread via Digitalmars-d-bugs

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

  Issue ID: 17643
   Summary: std.traits.getSymbolsByUDA doesn't work with private
attributes
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

There's currently a publicly documented example about using getSymbolsByUDA
with private attributes. This only works because the example is in std.traits 

> dmd -c test.d
tuple(a)

---
import std.traits;

enum Attr;
struct A
{
@Attr int a;
@Attr private int c;
}

pragma(msg, getSymbolsByUDA!(A, Attr).stringof);
---

--

[Issue 11997] rdmd should search it's binary path for the compiler

2017-07-12 Thread via Digitalmars-d-bugs

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from Vladimir Panteleev  ---
https://github.com/dlang/tools/pull/250

--

[Issue 17630] DMD treats imports as public imports when selectively imported

2017-07-12 Thread via Digitalmars-d-bugs

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

--- Comment #2 from Seb  ---
> Can you investigate this a bit more and add that info to the bug report, 
> including that it's been around for a while?


The leaked symbols are [found in the local `symtab`
table](https://github.com/dlang/dmd/blob/master/src/ddmd/dsymbol.d#L1306)

```
test17630b.ScopeDsymbol::search(ident='Erase', flags=x0)
found in locals = 'test17630b.Erase'
test17630b.ScopeDsymbol::search(ident='Erase', flags=x28)
found in locals = 'test17630b.Erase'
```

However, the next four lines in the log shouldn't happen:

```
test17630a.ScopeDsymbol::search(ident='Erase', flags=x0)
found in locals = 'test17630a.Erase'
test17630a.ScopeDsymbol::search(ident='Erase', flags=x28)
found in locals = 'test17630a.Erase'
__anonymous.ScopeDsymbol::search(ident='Erase', flags=x8)
found in locals = '__anonymous.Erase'
```

Now, when I look at the symbol table for test17630b it's built correctly:

```
DsymbolTable::insert(this = 0x7fc6d7dcbbe0, 'object')
DsymbolTable::insert(this = 0x7fc6d7dcbbe0, 'Erase')
DsymbolTable::insert(this = 0x7fc6d7dcbbe0, 'NoErase')
```

In fact even the members only get added for test17630b:

```
Import.addMember(this=object, sd=test17630b, sc=0x7f11f8e71b00)
Dsymbol::addMember('object')
Dsymbol::addMember(this = 0x7f11f8e71c20, 'object' scopesym = 'test17630b')
Dsymbol::addMember(this = 0x7f11f8e71c20, 'object' sds = 0x7f11fa2c2db0,
sds.symtab = 0x7f11f8e71d30)
Dsymbol::addMember('Erase')
Dsymbol::addMember(this = 0x7f11fa2c3aa0, 'Erase' scopesym = 'test17630b')
Dsymbol::addMember(this = 0x7f11fa2c3aa0, 'Erase' sds = 0x7f11fa2c2db0,
sds.symtab = 0x7f11f8e71d30)
Dsymbol::addMember('NoErase')
Dsymbol::addMember(this = 0x7f11fa2c3c60, 'NoErase' scopesym = 'test17630b')
Dsymbol::addMember(this = 0x7f11fa2c3c60, 'NoErase' sds = 0x7f11fa2c2db0,
sds.symtab = 0x7f11f8e71d30)
```

and in the main test file `Erase` doesn't get inserted into the symbol table:

```
__anonymous.ScopeDsymbol::search(ident='_Dmain', flags=x8)
__entrypoint.ScopeDsymbol::search(ident='_Dmain', flags=x28)
found in locals = '__entrypoint._Dmain'
Import::semantic('imports.test17630a.object') object
test17630a.ScopeDsymbol::importScope(object, 2)
Import::semantic('imports.test17630a.imports') test17630b
test17630a.ScopeDsymbol::importScope(test17630b, 2)
Import::semantic('imports.test17630b.object') object
test17630b.ScopeDsymbol::importScope(object, 2)
DsymbolTable::insert(this = 0x7f975b424780, 'fail17630')
DsymbolTable::insert(this = 0x7f975b424850, 'imports')
DsymbolTable::insert(this = 0x7f975b424920, 'imports')
DsymbolTable::insert(this = 0x7f975b4249f0, 'fail17630')
Import::semantic('__anonymous') test17630a
Import::load('__anonymous') 0x7f975c8294b0
```


> This seems like a fairly important import leak remaining, would be good to 
> explore how large it is. 

It's _pretty_ large. AFAICT all module-level imports, non-selective imports
leak their symbols.
However, even selective imports leak their selected symbols:

```d
import imports.test17630b; // works __falsely__ as public import
import imports.test17630b : Erase; // works __falsely__ as public import
```

Funnily even `private import X;` doesn't fix it.

--

[Issue 17630] DMD treats imports as public imports when selectively imported

2017-07-12 Thread via Digitalmars-d-bugs

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

--- Comment #1 from Seb  ---


Without the selective import:

test17630a.ScopeDsymbol::search(ident='Erase', flags=x0)
object.ScopeDsymbol::search(ident='Erase', flags=x1)
test17630b.ScopeDsymbol::search(ident='Erase', flags=x1)
found in locals = 'test17630b.Erase'
test17630a.ScopeDsymbol::search(ident='Erase', flags=x28)
test17630a.ScopeDsymbol::search(ident='Erase', flags=x30)
test17630a.ScopeDsymbol::search(ident='Erase', flags=x28)
test17630a.ScopeDsymbol::search(ident='Erase', flags=x30)
__anonymous.ScopeDsymbol::search(ident='Erase', flags=x8)
found in locals = '__anonymous.Erase'



With the selective import in foo:

__anonymous.ScopeDsymbol::search(ident='Erase', flags=x8)
__anonymous.ScopeDsymbol::search(ident='Erase', flags=x8)
fail17630.ScopeDsymbol::search(ident='Erase', flags=x28)
__anonymous.ScopeDsymbol::search(ident='Erase', flags=x28)
__anonymous.ScopeDsymbol::search(ident='Erase', flags=x10)
test17630a.ScopeDsymbol::search(ident='Erase', flags=x1)
__anonymous.ScopeDsymbol::search(ident='Erase', flags=x10)
fail17630.ScopeDsymbol::search(ident='Erase', flags=x30)
object.ScopeDsymbol::search(ident='Erase', flags=x1)
...
fail_compilation/fail17630.d(11): Error: undefined identifier Erase


With a selective import of another symbol in bar:


test17630b.ScopeDsymbol::search(ident='NoErase', flags=x0)
found in locals = 'test17630b.NoErase'
test17630b.ScopeDsymbol::search(ident='NoErase', flags=x28)
found in locals = 'test17630b.NoErase'
test17630a.ScopeDsymbol::search(ident='Erase', flags=x0)
object.ScopeDsymbol::search(ident='Erase', flags=x1)
test17630a.ScopeDsymbol::search(ident='Erase', flags=x2)
object.ScopeDsymbol::search(ident='Erase', flags=x3)
test17630a.ScopeDsymbol::search(ident='Erase', flags=x2)
object.ScopeDsymbol::search(ident='Erase', flags=x3)
test17630a.ScopeDsymbol::search(ident='Erase', flags=x2)
object.ScopeDsymbol::search(ident='Erase', flags=x3)
test17630a.ScopeDsymbol::search(ident='Erase', flags=x2)
fail_compilation/fail17630.d(9): Error: module imports.test17630a import
'Erase' not found, did you mean alias 'NoErase'?


Full test case for the DMD test suite:

diff --git a/test/fail_compilation/fail17630.d
b/test/fail_compilation/fail17630.d
new file mode 100644
index 0..08fe72a36
--- /dev/null
+++ b/test/fail_compilation/fail17630.d
@@ -0,0 +1,12 @@
+/*
+TEST_OUTPUT:
+---
+fail_compilation/fail17630.d(12): Deprecation: imports.test17630a.Erase is not
visible from module fail17630
+---
+*/
+void main()
+{
+import imports.test17630a : Erase;
+//import imports.test17630a; // A non-selective import correctly errors
+assert(Erase == 2);
+}
diff --git a/test/fail_compilation/imports/test17630a.d
b/test/fail_compilation/imports/test17630a.d
new file mode 100644
index 0..68003b1f9
--- /dev/null
+++ b/test/fail_compilation/imports/test17630a.d
@@ -0,0 +1,4 @@
+module imports.test17630a;
+//import imports.test17630b; // works __falsely__ as public import
+//import imports.test17630b : Erase; // <- works __falsely__ as public import
+import imports.test17630b : NoErase; // <- works correctly as private import
diff --git a/test/fail_compilation/imports/test17630b.d
b/test/fail_compilation/imports/test17630b.d
new file mode 100644
index 0..c02f4f88a
--- /dev/null
+++ b/test/fail_compilation/imports/test17630b.d
@@ -0,0 +1,3 @@
+module imports.test17630b;
+int Erase = 2;
+int NoErase = 3;

--

[Issue 17193] selective imports -> deprecation warnings even if symbol is not used

2017-07-12 Thread via Digitalmars-d-bugs

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||diagnostic, rejects-valid

--- Comment #1 from Vladimir Panteleev  ---
Same with a fully qualified import (`static import foo; foo.toUTF8("aoeu");` in
your example).

--

[Issue 17642] New: Specify in the documentation for destructors the problem with the error InvalidMemoryOperationError

2017-07-12 Thread via Digitalmars-d-bugs

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

  Issue ID: 17642
   Summary: Specify in the documentation for destructors the
problem with the error InvalidMemoryOperationError
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: criman...@gmail.com

The current implementation of GC is not re-enterable so users regularly receive
an unexpected InvalidMemoryOperationError. The only reliable way to avoid this
error is not to create garbage-collected instances of objects or structs with
non-@nogc destructor. There is no information about it in the documentation,
except error itself description. Nobody reads all possible errors descriptions
before writing code. So then user faced this error usually it's too late to
change architecture and think about ~this() @nogc.

So I propose to add info about this error and how to avoid this to destructors
documentation page 
https://dlang.org/spec/class.html#destructors
or as minimum write a short warning about and give the link to the page with
extended info https://wiki.dlang.org/InvalidMemoryOperationError

--

[Issue 16432] JSON incorrectly parses to string

2017-07-12 Thread via Digitalmars-d-bugs

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

Tomer Filiba (weka)  changed:

   What|Removed |Added

 CC|to...@weka.io   |

--

[Issue 12736] @nogc std.algorithm.all

2017-07-12 Thread via Digitalmars-d-bugs

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

Jon Degenhardt  changed:

   What|Removed |Added

 CC||jrdemail2000-dl...@yahoo.co
   ||m

--- Comment #2 from Jon Degenhardt  ---
Seems a legitimate enhancement request, and in line with the longer term goal
of having Phobos be @nogc when possible. In this particular case, there doesn't
appear to be any reason why the functionality implemented by std.algorithm.all
cannot be @nogc. And, std.algorithm.find could be @nogc as well in this case.

Personally though, I would hesitate to write an enhancement request against
each individual function in Phobos for every attribute, and instead have a
larger placeholder ticket for larger blocks of Phobos, for example, a ticket
for all of std.algorithm. The above is a policy question of course, but if done
this way then this ticket could be closed as a duplicate of the larger ticket,
rather than closing it as invalid.

As aside: std.algorithm.find is @nogc for certain argument types. Example:

@nogc @safe nothrow pure unittest
{
import std.algorithm : find;
import std.range : iota;

assert(find(iota(1,5), 3) == iota(3,5));
}

--

[Issue 7839] std.range.countFrom() too

2017-07-12 Thread via Digitalmars-d-bugs

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #4 from Seb  ---
Wouldn't it make sense to add support for BigInt to iota instead of creating
yet another range?

--

[Issue 16989] Ensure that every Phobos function has Returns/Params

2017-07-12 Thread via Digitalmars-d-bugs

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
DScanner now supports partial blacklisting and
`properly_documented_public_functions` can be fixed modulewise.

--

[Issue 17640] std.concurrenct writeln conflicts with std.stdio writeln in unittests

2017-07-12 Thread via Digitalmars-d-bugs

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

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

https://github.com/dlang/phobos/commit/a5afe1609feed83f2233cad80a54201dccdd4b1e
Fix Issue 17640 - std.concurrenct writeln conflicts with std.stdio writeln in
unittests

https://github.com/dlang/phobos/commit/72c1c2bc3a27f529128a453bc8327a76cd162e2f
Merge pull request #5600 from wilzbach/fix-17640

Fix Issue 17640 - std.concurrenct writeln conflicts with std.stdio writeln in
unittests
merged-on-behalf-of: Jack Stouffer 

--

[Issue 17640] std.concurrenct writeln conflicts with std.stdio writeln in unittests

2017-07-12 Thread via Digitalmars-d-bugs

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

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

   What|Removed |Added

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

--

[Issue 16432] JSON incorrectly parses to string

2017-07-12 Thread via Digitalmars-d-bugs

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

Seb  changed:

   What|Removed |Added

   Keywords||pull
 CC||greensunn...@gmail.com

--

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

2017-07-12 Thread via Digitalmars-d-bugs

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

Seb  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #3 from Seb  ---
I ran your program 15x on my machine with 2.074.0 and 2.075.0-b4 and couldn't
reproduce this. Closing this as WORKSFORME then - please reopen if this is
still an issue for you with the latest release.

--

[Issue 17040] Examples should have an import of itself

2017-07-12 Thread via Digitalmars-d-bugs

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

Seb  changed:

   What|Removed |Added

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

--- Comment #2 from Seb  ---
Since a couple of weeks we have a export button on the right which takes you to
run.dlang.io (and interactive playground). On export the current module +
std.stdio are imported and the code is wrapped into a void main() { ...}, s.t.
it's runnable everywhere.
I am hence closing this as FIXED, please reopen if you disagree and still think
that the examples should have the respective imported modules directly listed
on dlang.org, please reopen.

--

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

2017-07-12 Thread via Digitalmars-d-bugs

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
https://github.com/dlang/phobos/pull/5582 reduces the list again and contains a
list of missing modules on the blacklist:

- std.math
- std.stdio
- stdx.allocator.building_blocks.quantizer
- stdx.allocator.building_blocks.free_list
- std.traits

--

[Issue 17082] assert in std.algorithm.iteration splitter example does not compile.

2017-07-12 Thread via Digitalmars-d-bugs

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

Seb  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||greensunn...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #1 from Seb  ---
Thanks for reporting!

This was probably due to the low RAM of the DPaste backend. We switched to
DTour as backend a few weeks a go and now all examples work online.

Btw on every PR we automatically check that all examples compile, so if you see
a "Temporarily unavailable" that's most likely related to the backend then.

--

[Issue 17107] Runnign phobos unittests do not work with PIE

2017-07-12 Thread via Digitalmars-d-bugs

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

Seb  changed:

   What|Removed |Added

   Keywords||pull
 CC||greensunn...@gmail.com

--- Comment #2 from Seb  ---
https://github.com/dlang/phobos/pull/5586

--

[Issue 17127] bad example code for std.concurrency.Generator

2017-07-12 Thread via Digitalmars-d-bugs

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

Seb  changed:

   What|Removed |Added

   Keywords||pull
 CC||greensunn...@gmail.com

--- Comment #1 from Seb  ---
https://github.com/dlang/phobos/pull/5603

--

[Issue 17641] TypeInfo for two identical delegates (or functions) are not equal to each other

2017-07-12 Thread via Digitalmars-d-bugs

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
(In reply to andronkin from comment #0)
> auto d1 = delegate void(uint a) { writeln(a); };
> auto d2 = delegate void(uint a) {};
> 
> assert(typeid(d1) is typeid(d2)); // FAILED! Although type hasn't been
> changed...

The type of d1 has changed. Try printing them with `pragma(msg, ...)`:


pragma(msg, typeof(d1));
pragma(msg, typeof(d2));


Prints:


void delegate(uint a) @safe
void delegate(uint a) pure nothrow @nogc @safe


You see that d1 is not `pure nothrow @nogc`. Because `writeln` isn't.

> Also, the string representation of typeid(d1) is "void delegate()", although
> there must be a "void delegate(uint)".

Yeah, that looks wrong.

--

[Issue 17641] New: TypeInfo for two identical delegates (or functions) are not equal to each other

2017-07-12 Thread via Digitalmars-d-bugs

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

  Issue ID: 17641
   Summary: TypeInfo for two identical delegates (or functions)
are not equal to each other
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: andron...@gmail.com

Example:

auto d1 = delegate void(uint a) {};
auto d2 = delegate void(uint a) {};

assert(typeid(d1) is typeid(d2)); // OK

But in another case:

auto d1 = delegate void(uint a) { writeln(a); };
auto d2 = delegate void(uint a) {};

assert(typeid(d1) is typeid(d2)); // FAILED! Although type hasn't been
changed...

Also, the string representation of typeid(d1) is "void delegate()", although
there must be a "void delegate(uint)".

--

[Issue 5418] std.math.lround not implemented on win32 and not documented

2017-07-12 Thread via Digitalmars-d-bugs

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

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

https://github.com/dlang/phobos/commit/4ea051f17a1308a92ce93d0cb7e5ea38c2de1e18
Issue 5418 - std.math.lround not implemented on win32 and not documented

https://github.com/dlang/phobos/commit/42c3b6b75159daa9d976933d42a3a4fdd1fa9868
Merge pull request #5599 from RazvanN7/Issue_5418

Issue 5418 - std.math.lround not implemented on win32 and not documented
merged-on-behalf-of: Sebastian Wilzbach 

--

[Issue 4541] Intrinsic functions do not have pointers

2017-07-12 Thread via Digitalmars-d-bugs

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

Mathias Lang  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
  Component|phobos  |dmd
 Resolution|FIXED   |---

--- Comment #9 from Mathias Lang  ---
I strongly disagree with closing this bug.

> Even though using core.math results in link failure, I do not think this is a 
> problem since that is the runtime library and who uses it should know that 
> the functions declared there are intrinsics.

Relying on user knowing of internal details is not a solution. Moreover, this
doesn't take into account generic code. If one write a template that accept a
static function via a template this argument, do you really expect this person
to handle the case of someone passing an intrinsic explicitly ?

Intrinsics shouldn't differ from regular functions.

> Anyway, this is not a phobos bug anymore and I don't think it is a druntime 
> one either. Closing as fixed.

The correct course of action would be to properly tag the bug as being within
DMD.

--

[Issue 15768] std.stdio.trustedStdout accesses __gshared data without synchronization.

2017-07-12 Thread via Digitalmars-d-bugs

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

--- Comment #9 from Jack Stouffer  ---
(In reply to John Colvin from comment #8)
> Is this resolved now? I see a fair amount of synchronisation in makeGlobal,
> which is what std{in,out,err} are aliased to now.

Nope. I was able to reproduce this with Phobos master.

--

[Issue 17640] std.concurrenct writeln conflicts with std.stdio writeln in unittests

2017-07-12 Thread via Digitalmars-d-bugs

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

Seb  changed:

   What|Removed |Added

Summary|std.concurrenct writeln |std.concurrenct writeln
   |conflicts std.stdio writeln |conflicts with std.stdio
   |in unittests|writeln in unittests

--

[Issue 17640] New: std.concurrenct writeln conflicts std.stdio writeln in unittests

2017-07-12 Thread via Digitalmars-d-bugs

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

  Issue ID: 17640
   Summary: std.concurrenct writeln conflicts std.stdio writeln in
unittests
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

test/utils.d(100,20): Error: std.stdio.writeln!(string, MapResult!(__lambda4,
APIExpectation[])).writeln at
/home/travis/dlang/dmd-master-2017-07-12/linux/bin64/../../src/phobos/std/stdio.d(3553,6)
conflicts with std.concurrency.writeln!(string, MapResult!(__lambda4,
APIExpectation[])).writeln at
/home/travis/dlang/dmd-master-2017-07-12/linux/bin64/../../src/phobos/std/concurrency.d(48,10)
test/utils.d(259,20): Error: std.stdio.writeln!string.writeln at
/home/travis/dlang/dmd-master-2017-07-12/linux/bin64/../../src/phobos/std/stdio.d(3553,6)
conflicts with std.concurrency.writeln!string.writeln at
/home/travis/dlang/dmd-master-2017-07-12/linux/bin64/../../src/phobos/std/concurrency.d(48,10)
test/utils.d(295,20): Error: std.stdio.writeln!string.writeln at
/home/travis/dlang/dmd-master-2017-07-12/linux/bin64/../../src/phobos/std/stdio.d(3553,6)
conflicts with std.concurrency.writeln!string.writeln at
/home/travis/dlang/dmd-master-2017-07-12/linux/bin64/../../src/phobos/std/concurrency.d(48,10)
test/utils.d(315,20): Error: std.stdio.writeln!string.writeln at
/home/travis/dlang/dmd-master-2017-07-12/linux/bin64/../../src/phobos/std/stdio.d(3553,6)
conflicts with std.concurrency.writeln!string.writeln at
/home/travis/dlang/dmd-master-2017-07-12/linux/bin64/../../src/phobos/std/concurrency.d(48,10)

https://travis-ci.org/dlang-bots/dlang-bot/jobs/252702252

--

[Issue 17622] inline for m64 fails web APPS

2017-07-12 Thread via Digitalmars-d-bugs

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

--- Comment #3 from steven kladitis  ---
void main() {
import std.stdio, std.base64, std.net.curl, std.string;

const f = "http://rosettacode.org/favicon.ico".get.representation;
Base64.encode(f).writeln;
}



 the above fails in -m32 or -m64 when using -inline
-- without -inline they  execute immediately.

--

[Issue 15771] FileLogger should create the output directory if it does not exist

2017-07-12 Thread via Digitalmars-d-bugs

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

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

https://github.com/dlang/phobos/commit/e85381ee42652029a8b1c8d8397aee78c2ae7139
Fix Issue 15771 - FileLogger should create the output directory if it does not
exist

https://github.com/dlang/phobos/commit/d27a3bf9d53c9b0dd35f70c5060891d68dd6ce6a
Merge pull request #5594 from RazvanN7/Issue_15771

Fix Issue 15771 - FileLogger should create the output directory if it does not
exist
merged-on-behalf-of: Sebastian Wilzbach 

--

[Issue 15771] FileLogger should create the output directory if it does not exist

2017-07-12 Thread via Digitalmars-d-bugs

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

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

   What|Removed |Added

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

--

[Issue 17638] A pragma inside a function body is seen as a statement

2017-07-12 Thread via Digitalmars-d-bugs

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

--- Comment #1 from anonymous4  ---
This can't be a declaration, because empty declaration can't have attributes:
---
static;
---
Error: declaration expected following attribute, not ';'

--

[Issue 17395] std.file.rmdirRecurse isn't @safe

2017-07-12 Thread via Digitalmars-d-bugs

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

Seb  changed:

   What|Removed |Added

   Keywords||bootcamp

--

[Issue 4541] Intrinsic functions do not have pointers

2017-07-12 Thread via Digitalmars-d-bugs

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

RazvanN  changed:

   What|Removed |Added

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

--- Comment #8 from RazvanN  ---
I think that this issue is no longer valid since using the std.math wrappers
results in successful compilation. Even though using core.math results in link
failure, I do not think this is a problem since that is the runtime library and
who uses it should know that the functions declared there are intrinsics.
Anyway, this is not a phobos bug anymore and I don't think it is a druntime one
either. Closing
as fixed.

--

[Issue 4535] std.range could have a takeWhile!pred(range) function

2017-07-12 Thread via Digitalmars-d-bugs

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

--- Comment #10 from RazvanN  ---
PR : https://github.com/dlang/phobos/pull/5563

We should either close this or work on the PR.

--

[Issue 12955] Deprecated std.datetime.measureTime. It's redundant functionality.

2017-07-12 Thread via Digitalmars-d-bugs

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

--- Comment #3 from RazvanN  ---
Ok. Close this when you think is the best time (now or after the deprecation
takes place)

--

[Issue 12955] Deprecated std.datetime.measureTime. It's redundant functionality.

2017-07-12 Thread via Digitalmars-d-bugs

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

--- Comment #2 from Jonathan M Davis  ---
It's going to be. It's marked as shceduled for deprecation at the moment, and
I'll be deprecating it soon.

--

[Issue 15768] std.stdio.trustedStdout accesses __gshared data without synchronization.

2017-07-12 Thread via Digitalmars-d-bugs

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

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com

--- Comment #8 from John Colvin  ---
Is this resolved now? I see a fair amount of synchronisation in makeGlobal,
which is what std{in,out,err} are aliased to now.

--

[Issue 12963] posix.mak hardcodes $(CC) as cc on non Windows system

2017-07-12 Thread via Digitalmars-d-bugs

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

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |INVALID

--- Comment #1 from RazvanN  ---
If another compiler needs to be used, a different branch can be easily added.
Closing as invalid

--

[Issue 12955] Deprecated std.datetime.measureTime. It's redundant functionality.

2017-07-12 Thread via Digitalmars-d-bugs

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

RazvanN  changed:

   What|Removed |Added

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

--- Comment #1 from RazvanN  ---
ping. Should we still deprecate it?

--

[Issue 12867] std.traits.fullyQualifiedName fails on ClassName.staticMember.memberOfStruct

2017-07-12 Thread via Digitalmars-d-bugs

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

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |WORKSFORME

--- Comment #1 from RazvanN  ---
Could not reproduce on Ubuntu 16.04 latest phobos and dmd.

--

[Issue 17639] std.math.approxEqual accepts return of isNaN (bool) as argument

2017-07-12 Thread via Digitalmars-d-bugs

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

Simen Kjaeraas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||simen.kja...@gmail.com
 Resolution|--- |INVALID

--- Comment #1 from Simen Kjaeraas  ---
There's nothing particular about approxEqual in this case - at least 26 out of
70 functions in std.math accept bools for at least one of their parameters.

This bug report basically boils down to this code:

float f = false;

This compiles and is valid D. (and the value of f is 0)

--

[Issue 12736] @nogc std.algorithm.all

2017-07-12 Thread via Digitalmars-d-bugs

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

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |INVALID

--- Comment #1 from RazvanN  ---
Why is this an issue? all calls find which is non-nogc. Closing as invalid

--

[Issue 17639] std.math.approxEqual accepts return of isNaN (bool) as argument

2017-07-12 Thread via Digitalmars-d-bugs

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

drug007  changed:

   What|Removed |Added

  Component|dmd |phobos

--

[Issue 17639] New: std.math.approxEqual accepts return of isNaN (bool) as argument

2017-07-12 Thread via Digitalmars-d-bugs

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

  Issue ID: 17639
   Summary: std.math.approxEqual accepts return of isNaN (bool) as
argument
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: drug2...@bk.ru

Found by typo, forget to remove `isNaN` and code still compiles giving wrong
result:
```
import std.math;

int main()
{
float a = 0, b = 10_000;

static assert (!__traits(compiles, q{
// isNaN wasn't removed during copy-paste
// but code still compiles with wrong result
assert (a.approxEqual(b.isNaN) == false);
}), "This code must not compile!");

return 0;
}
```

--

[Issue 1085] Need to add ability to detach threads.

2017-07-12 Thread via Digitalmars-d-bugs

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com
  Component|phobos  |druntime
   Assignee|dvdfr...@users.sf.net   |nob...@puremagic.com

--- Comment #6 from RazvanN  ---
This is a druntime issue. Changing component to druntime

--

[Issue 16062] Add 'clear' method to OutBuffer (std.outbuffer)

2017-07-12 Thread via Digitalmars-d-bugs

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

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

https://github.com/dlang/phobos/commit/09ab8e96e33e8a41b735928f38629536fba883b6
Fix Issue 16062 - Add 'clear' method to OutBuffer (std.outbuffer)

https://github.com/dlang/phobos/commit/a1f274dca6da79d5cfed2382ec9cae867cf25a9c
Merge pull request #5593 from RazvanN7/Issue_16062

Fix Issue 16062 - Add 'clear' method to OutBuffer (std.outbuffer)
merged-on-behalf-of: Sebastian Wilzbach 

--

[Issue 17638] A pragma inside a function body is seen as a statement

2017-07-12 Thread via Digitalmars-d-bugs

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||spec

--

[Issue 4535] std.range could have a takeWhile!pred(range) function

2017-07-12 Thread via Digitalmars-d-bugs

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

--- Comment #9 from timon.g...@gmx.ch ---
(In reply to Jonathan M Davis from comment #8)
> (In reply to timon.gehr from comment #7)
> > (In reply to Jonathan M Davis from comment #6)
> > > We already have until,
> > > which does what takeWhile would do - it just has an arguably worse name. 
> > > Is
> > > there something about until that does not fulfill what takeWhile would do?
> > 
> > In many (most?) circumstances it is just silly to have to specify a
> > condition to detect the first element that you do /not/ want included in
> > your range. There is a reason 'filter' keeps the elements for which the
> > predicate evaluates to 'true' and not those for which it evaluates to
> > 'false'.
> 
> True, in may circumstances, having to negate your predicate is annoying, but
> when I tried to get takeWhile and dropWhile added on that basis several
> years ago, Andrei vetoed it, because it was trivial to just negate the
> predicate, and he's right. It may be a bit annoying, but it is trivial.
> ...

I'm not using Phobos in order to get annoyed by trivialities, and neither are
the people who will need to read my code.
It is not inadvisable to not condone double-negation in text for which we want
to avoid that it does not fail to be hard to digest.


> There's still some value in takeWhile on the basis of user friendliness if
> you have a predicate that would need to be negated to be used with until,
> and some folks do go looking for takeWhile and fail to find until (though
> until's docs do now mention that it's essentially takeWhile), but we do
> generally try to avoid adding extremely simple functions to Phobos, and if
> takeWhile or dropWhile were added, they would almost certainly be added as
> simple wrappers around until and find respectively.
> ...

User friendliness, reader friendliness, name standardization.

> So, unless someone can convince Andrei that having to negate the predicate
> is onerous enough to merit adding the opposite functions and/or the negated
> versions are more common than what we have,

It is controversial that takeWhile is more commonly useful that until?

> I think that it's pretty clear
> that neither takeWhile nor dropWhile are going to be added, because we
> already have the functionality that they provide, even if it does require
> that you sometimes negate your predicate.

It is wrong to think in terms of "functionality" for combiners used in a
functional program.
Every additional negation makes a one-liner harder to understand even if it
inconveniences its construction in a minor (but still, unnecesssary) way.

--

47 matches

Mail list logo