[Issue 15656] broken link in datetime.d documentation

[via Digitalmars-d-bugs]

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

Gerald Jansen  changed:

   What|Removed |Added

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

--- Comment #2 from Gerald Jansen  ---
(In reply to ag0aep6g from comment #1)
> I suppose this is about the ddox pages [1], right? 

Yes. Okay so this is a ddox issue and presumably it is well known so I'll close
this issue.

--

[Issue 15656] broken link in datetime.d documentation

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
I suppose this is about the ddox pages [1], right? The link is broken there,
but it's fine on the ddoc pages [2].

The underscore is there for a reason: Without it, "datetime" would be
highlighted by ddoc, which would garble the URL, breaking the link.

That ddox carries over the underscore literally seems to be a bug, or at least
an incompatibility between ddox and ddoc.

So, fixing this will be more complicated than just removing the underscore,
unfortunately.


[1] ,

[2] ,


--

[Issue 15656] New: broken link in datetime.d documentation

[via Digitalmars-d-bugs]

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

  Issue ID: 15656
   Summary: broken link in datetime.d documentation
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: jansen.ger...@gmail.com

tldr; in std/datetime.d, http://dlang.org/intro-to-_datetime.html should be
http://dlang.org/intro-to-datetime.html

I tried to fix this myself using the "Improve this page" but that mysteriously
took me to an EMPTY datetime.d file in github:
D-Programming-Language/phobos/std/datetime.d, with a warning  "You’re editing a
file in a project you don’t have write access to. Submitting a change to this
file will write it to a new branch in your fork jansengb/phobos, so you can
send a pull request."

Okay, so I fork phobos in github and navigate to datetime.d. Whoa, the file is
1.38 Mb, too big to be viewed/edited in github. Okay, I give up.

--

[Issue 15629] [REG2.066.0] wrong code with "-O -inline" but correct with "-O"

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

Summary|[REG] wrong code with "-O   |[REG2.066.0] wrong code
   |-inline" but correct with   |with "-O -inline" but
   |"-O"|correct with "-O"

--- Comment #4 from Kenji Hara  ---
(In reply to Kenji Hara from comment #3)
> Dustmited case code:

Sorry, the reduced code cannot reproduce exactly same regression with the
original.
I'll open one more issue for that.

Correct minimized code is:

void main()
{
int[] a = [3];
int value = abs(a[0]);
assert(a[0] == 3);
writeln(value, " ", a);
}

Num abs(Num)(Num x)
{
return x >= 0 ? x : -x;
}

struct File
{
struct LockingTextWriter
{
this(File) {}

~this() @trusted {}
}

auto lockingTextWriter()
{
return LockingTextWriter();
}
}

File stdout;

void writeln(T...)(T args)
{
stdout.lockingTextWriter();
}

Introduced in:
https://github.com/D-Programming-Language/dmd/pull/3620
and its fixup PR:
https://github.com/D-Programming-Language/dmd/pull/3656

So this is a regression from 2.066.0.

--

[Issue 15629] [REG2.066.0] wrong code with "-O -inline" but correct with "-O"

[via Digitalmars-d-bugs]

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

--- Comment #5 from Kenji Hara  ---
(In reply to Kenji Hara from comment #4)
> Sorry, the reduced code cannot reproduce exactly same regression with the
> original.
> I'll open one more issue for that.

Ah, I got understanding. The reduced case in comment#3 has generated wrong code
with -inline, since the change by PR#4474:
https://github.com/D-Programming-Language/dmd/pull/4474

However, comment#3 and comment#4 are essentially same. The only one difference
is the parenthesis on stdout.lockingTextWriter(); in writeln template function.
So, this wrong-code issue in the comment#3 case was hidden by issue 14264, and
it's *fixed* by PR#4474. Therefore the two cases can hit this issue with
current master.

--

[Issue 15656] broken link in datetime.d documentation

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #3 from ag0ae...@gmail.com ---
(In reply to Gerald Jansen from comment #2)
> Yes. Okay so this is a ddox issue and presumably it is well known so I'll
> close this issue.

I don't think it's well known. At least, this is the first time it's been
pointed out to me. This may have to be fixed in ddox, but the broken links are
an issue for phobos/dlang.org. So this is definitely not invalid. Reopening.

--

[Issue 15659] SList: clear() can cause crash

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/phobos/commit/b847c5a194f0eea8429c50c8a2539ca82ff2bb55
Fix Issue 15659 - fix crash in SList.clear()

https://github.com/D-Programming-Language/phobos/commit/f62c716072380bb52b9918c8d8d1fd7d3079b7fb
Merge pull request #3980 from sigod/slist-clear-crash

Fix Issue 15659 - fix crash in SList.clear()

--

[Issue 15661] Destructor called while object still alive

[via Digitalmars-d-bugs]

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

--- Comment #1 from Daniel Kozak  ---
in 2.066.1 and before it works as expected

--

[Issue 15661] Destructor called while object still alive

[via Digitalmars-d-bugs]

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

Daniel Kozak  changed:

   What|Removed |Added

 CC||kozz...@gmail.com
 OS|Windows |All
   Severity|major   |regression

--

[Issue 15619] [REG 2.066] Floating-point x86_64 codegen regression, when involving array ops

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

   Keywords||wrong-code
Summary|[REG 2.068] Floating-point  |[REG 2.066] Floating-point
   |x86_64 codegen regression,  |x86_64 codegen regression,
   |when involving array ops|when involving array ops

--- Comment #2 from Kenji Hara  ---
Both original and reduced code generate wrong result since 2.066.0 (2.065 is
ok).

--

[Issue 15657] New: [internal] StructLiteralExp.sinst comparison in constfolding needs to be removed

[via Digitalmars-d-bugs]

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

  Issue ID: 15657
   Summary: [internal] StructLiteralExp.sinst comparison in
constfolding needs to be removed
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: k.hara...@gmail.com

This is a task reminder issue.

https://github.com/D-Programming-Language/dmd/pull/1301/files#r52168903

At least, StructLiteralExp.sinst is a backend-specific field. Using it for
semantic analysis causes a layer violation.

--

[Issue 15660] New: result of pure function

[via Digitalmars-d-bugs]

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

  Issue ID: 15660
   Summary: result of pure function
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: iakt...@gmail.com

Compiler can't determine result of pure function is not unique

import std.stdio;

struct S
{
void[] arr; // with int instead of void program doesn't compiles

auto f() pure @safe
{
int[] a = new int[4];
arr = a;
return a;
}
}
void main() @safe
{
S s;
immutable a = s.f();
int[] b = (cast(int[])s.arr);
writeln(a); // [0, 0, 0, 0]
b[0] = 1;
writeln(a); // [1, 0, 0, 0]
}

--

[Issue 15660] breack "immutable" with pure function and mutable params

[via Digitalmars-d-bugs]

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

Iakh  changed:

   What|Removed |Added

Summary|result of pure function |breack "immutable" with
   ||pure function and mutable
   ||params

--

[Issue 15658] isFile isn't a template

[via Digitalmars-d-bugs]

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

Cédric Picard  changed:

   What|Removed |Added

  Component|dmd |phobos

--

[Issue 15658] New: isFile isn't a template

[via Digitalmars-d-bugs]

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

  Issue ID: 15658
   Summary: isFile isn't a template
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: cpic...@openmailbox.org

I get a strange error when not using UFCS with isFile on a DirEntry with DMD
v0.270.0

To reproduce:

$ cat test.d
void main() {
import std.file, std.algorithm;
dirEntries("/tmp/", SpanMode.breadth).filter!(f => isFile(f));
}

$ dmd test.d
/usr/include/dlang/dmd/std/file.d(1743): Error: name.isFile isn't a
template
test.d(7): Error: template instance std.file.isFile!(DirEntry) error
instantiating
/usr/include/dlang/dmd/std/algorithm/iteration.d(985):instantiated
from here: __lambda2!(DirEntry)
/usr/include/dlang/dmd/std/algorithm/iteration.d(944):instantiated
from here: FilterResult!(__lambda2, DirIterator)
test.d(7):instantiated from here: filter!(DirIterator)


It is easy to circumvent though:

$ cat test2.d
void main() {
import std.file, std.algorithm;
dirEntries("/tmp/", SpanMode.breadth).filter!(f => f.isFile);
}
$ dmd test.d


--

[Issue 15658] isFile isn't a template

[via Digitalmars-d-bugs]

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

Cédric Picard  changed:

   What|Removed |Added

   Severity|enhancement |normal

--

[Issue 15659] New: SList: clear() can cause crash

[via Digitalmars-d-bugs]

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

  Issue ID: 15659
   Summary: SList: clear() can cause crash
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: sigod.m...@gmail.com

This code crashes:

import std.container.slist;

SList!int s;
s.clear();

--

[Issue 15659] SList: clear() can cause crash

[via Digitalmars-d-bugs]

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

--- Comment #1 from sigod  ---
https://github.com/D-Programming-Language/phobos/pull/3980

--

[Issue 15660] breack "immutable" with pure function and mutable params

[via Digitalmars-d-bugs]

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

--- Comment #1 from Iakh  ---
Also this works

import std.stdio;

class A
{
int i;
}

class B : A {}
struct S
{
A a;

auto f() pure @safe
{
B b = new B;
a = b;
return b;
}
}

void main() @safe
{
S s;
immutable a = s.f();
A b = s.a;
writeln(a.i);
b.i = 1;
writeln(a.i);
}

--

[Issue 15661] New: Destructor called while object still alive

[via Digitalmars-d-bugs]

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

  Issue ID: 15661
   Summary: Destructor called while object still alive
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: matt.elk...@gmail.com

In the code below the TileView destructor is called twice (see the output at
the bottom). The first call of the destructor appears to occur while the
TileView object is still alive. The expected output (also listed at the bottom)
occurs if any of a number of changes are made to the code, including but
probably not limited to:
* Creating the TextureHandles directly rather than calling create()
* Using only one argument to TileView's constructor
* Removing TextureHandle's empty destructor

This is on DMD 2.070 32-bit, running on 64-bit Windows 7.

[code]
import std.stdio;

struct TextureHandle
{
~this() {}
}

TextureHandle create() {return TextureHandle();}

 struct TileView
 {
 @disable this();
 @disable this(this);
 this(TextureHandle a, TextureHandle b) {}
 ~this() {writeln("HERE2");}
 }

 struct View
 {
 this(int)
 {
 writeln("HERE1a");
 m_tileView = TileView(create(), create());
 writeln("HERE1b");
 }

 private TileView m_tileView;
}

unittest
{
auto v = View(5);
}
[/code]

[output]
HERE1a
HERE2
HERE1b
HERE2
[/output]

[expected_output]
HERE1a
HERE1b
HERE2
[/expected_output]

--

[Issue 15662] New: Cannot move struct with defined opAssign due to @disabled post-blit

[via Digitalmars-d-bugs]

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

  Issue ID: 15662
   Summary: Cannot move struct with defined opAssign due to
@disabled post-blit
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: matt.elk...@gmail.com

Given the following definition:

[code]
import std.algorithm;

struct ResourceHandle(T, alias Deleter, T Default = T.init)
{
// Constructors/Destructor
this(T handle) {m_handle = handle;}
@disable this(this);
~this() {Deleter(m_handle);}

// Operators
@disable void opAssign(ref ResourceHandle lvalue);
ref ResourceHandle opAssign(ResourceHandle rvalue) {swap(m_handle,
rvalue.m_handle); return this;}

// Methods
@property inout(T) handle() inout {return m_handle;}
@property T handle(T handle) {Deleter(m_handle); m_handle = handle; return
m_handle;}
T release() {T result = m_handle; m_handle = Default; return result;}

private:
T m_handle = Default;
}
[/code]

The following will generate a compile error, making it awkward to move unique
resources:

[code]
unittest
{
alias RH = ResourceHandle!(uint, (uint) {});
RH[] handles;
handles ~= RH(5); // Compile error: ResourceHandle is not copyable because
it is annotated with @disable
}
[/code]

See discussion at
https://forum.dlang.org/post/nnjfuqeuprcswsjjf...@forum.dlang.org

At first I was uncertain whether this was a bug or by design, but Andrei
Alexandrescu confirmed the bug status in the linked discussion.

--