[Issue 18501] randomShuffle and partialShuffle should return their input argument

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

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

Basile B.  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from Basile B.  ---
pull: https://github.com/dlang/phobos/pull/6211

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

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

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

--- Comment #19 from Cy Schubert  ---
That probably makes sense. I can restrict FreeBSD 10 and 11 to an old release
of dmd. At least it addresses the issue going forward.

I'll rework the port the next time I visit it. I'm hoping to have this resolved
by the time FreeBSD 12 is released.

--

[Issue 18501] New: randomShuffle and partialShuffle should return their input argument

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

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

  Issue ID: 18501
   Summary: randomShuffle and partialShuffle should return their
input argument
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: b2.t...@gmx.com

Currently randomShuffle() and partialShuffle() are void functions. As a
consequence they cant be used as initializer.

--

[Issue 18492] DLang STL links are broken

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

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

Seb  changed:

   What|Removed |Added

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

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

Note that some links already have been removed in
https://github.com/dlang/phobos/pull/6097

--

[Issue 18408] [Home]

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

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

Seb  changed:

   What|Removed |Added

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

--- Comment #1 from Seb  ---
I'm not sure what this issue was about. Closing as INVALID.
Please clarify or open a new issue.

--

[Issue 18468] cannot use `synchronized {}` in @safe code

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

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

Seb  changed:

   What|Removed |Added

   Severity|enhancement |major

--

[Issue 17596] dmd d 2.073.2 and 2.074.1 interim generated dmd segfaults on FreeBSD 12-CURRENT

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

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

Walter Bright  changed:

   What|Removed |Added

   Severity|major   |blocker

--- Comment #18 from Walter Bright  ---
We don't seem to have a good solution for backwards compatibility, or anyone
particularly interested in supporting it. So we should just update the structs,
abandon the old FreeBSDs, and move on with the newer ones.

--

[Issue 18500] New: Be able to overwrite object.Object.toString with inout

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

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

  Issue ID: 18500
   Summary: Be able to overwrite object.Object.toString with inout
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: greensunn...@gmail.com

cat << EOF | dmd -c -o- -run -
void main()
{
class F
{
override string toString() inout @safe
{
return "Foo";
}
}
}
EOF

I'm aware that the current overloading rules don't really take `inout` into
account, but defining all three overloads is really annoying.


See also: https://issues.dlang.org/show_bug.cgi?id=9772 (removing toString from
Object)

--

[Issue 7879] format of class with not const toString()

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #4 from Seb  ---
PR from JackStouffer: https://github.com/dlang/phobos/pull/6207

--

[Issue 14439] aa's keys, values not usable in @safe context

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

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

Seb  changed:

   What|Removed |Added

   Keywords|pull|
 CC||greensunn...@gmail.com
Summary|aa's keys, values, byKey,   |aa's keys, values not
   |byValue not usable in @safe |usable in @safe context
   |context |

--

[Issue 8295] Struct member destructor can not be called from shared struct instance

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

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

--- Comment #14 from anonymous4  ---
(In reply to Marco Leise from comment #13)
> No it is not fine, because if we agree that top level qualifiers are free to
> change after a copy, and it seems sensible to say that the shared status of
> a copy is opt-in, then how would Dlang know that the struct copy should be
> destructed with the shared (or const to keep the analogy) destructor?
> Against the spec that put shared and const on equal ground, you would have
> to force all copies to be shared, too.
Implicit conversion for structs without indirection took precedence here. In
practice such struct seldom need elaborate management and you can opt out.
Though the same argument is true for const too.

> It is for example common to enter a critical section that protects some
> shared variables and then cast away shared.
As a general note you should consider what you do when you implement manual
multithreading. It can be also designed in many ways, casting may be not part
of the design.

> The problem we have understanding each other comes from shared not being
> fleshed out.
Your complaints are applicable to const too. That would mean const is not
fleshed out either?

> For me it is a tag that you apply temporarily while data is
> _currently_ in use by multiple threads, just so you don't casually read from
> or write to it and expect it to work.
Implicit casting violates this reasoning. When data used by multiple threads is
implicitly casted to thread local, how can it work in your understanding? What
will disallow to casually use it? Like for const. If you want shared data to be
different, implicit casting erases that difference without a trace, and the
point is lost, it becomes C type system where anything converts to anything
silently.

--

[Issue 18499] New: std.regex cannot handle (?i:)

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

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

  Issue ID: 18499
   Summary: std.regex cannot handle (?i:)
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: d...@me.com

Compiling and running the following code:

import std.regex;

void main()
{
regex(`(?i:)`);
}

Gives the following runtime exception:

phobos/std/regex/internal/parser.d(1018):  's', 'x', 'i', 'm' or '-' expected
after '(?'
Pattern with error: `(?i:` <--HERE-- `)`
Pattern with error: `(?i:` <--HERE-- `)`

Is this a bug or does std.regex not support this syntax?

--

[Issue 13957] 64 bit C ABI not followed for passing structs with floating+integer types

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

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||betterC, C++
 CC||bugzi...@digitalmars.com

--

[Issue 18498] New: File buffer overrun when using lexer-as-library

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

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

  Issue ID: 18498
   Summary: File buffer overrun when using lexer-as-library
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: bugzi...@digitalmars.com

As reported on the internet:
---
Reminds me of a bug I ran into recently while using the dmd lexer in a project.

When I passed any valid file to the lexer it worked fine.

When I passed a batch of valid files to the lexer, after a few files were
processed, it started to spit out all kinds of errors about invalid Unicode
code-points and ghost tokens. All those locations were past EOF.

When I passed in that particular file individually it worked like a charm.

When I over-sized the buffer that held a file by one char and set that to 0 it
worked for the batch of files.

--

[Issue 13957] 64 bit C ABI not followed for passing structs with floating+integer types

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

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com

--- Comment #1 from Andrei Alexandrescu  ---
Related: https://gist.github.com/Laeeth/9a51e12ce7273bf1ded322d5fb12ab18 from
Laeeth Isharc. His comment: "Works with gdc 7.3.0 and not LDC 1.7.0 (DMD front
end 2.077.1) or DMD v2.078.2"

--

[Issue 18497] New: windows uninstaller has an annoying really delete pop-up

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

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

  Issue ID: 18497
   Summary: windows uninstaller has an annoying really delete
pop-up
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: installer
  Assignee: nob...@puremagic.com
  Reporter: c...@dawg.eu

Was entered here https://github.com/dlang/installer/pull/121.
A proper solution to prevent edits or only remove unedited files is needed on
Windows as that's expected behavior for package installers.

--

[Issue 18267] array comparison broken in 2.078.3

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

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

John Colvin  changed:

   What|Removed |Added

   Keywords||industry
Summary|Linker errors compiling |array comparison broken in
   |std_data_json dub package   |2.078.3
   |with dmd 2.078.0|

--- Comment #3 from John Colvin  ---
Here is a standalone file that demonstrates what I think is a symptom of the
same bug:

% cat oops.d
struct JSONValue
{
TaggedAlgebraic payload;
alias payload this;
}

struct TaggedAlgebraic
{
auto opEquals(T)(T other) const
{
static assert(is(typeof(performOp!(JSONValue[], T;
return const(JSONValue[]).init == other;
}
}

bool performOp(T, A)(T value, A arg)
{
return value == arg;
}

% dmd oops.d
Undefined symbols for architecture x86_64:
  "_D6object__T8__equalsTxS4oops9JSONValueTxQsZQBgFNbAxQBdQfZb", referenced
from:
  _D4oops15TaggedAlgebraic__T8opEqualsTAxSQBm9JSONValueZQBbMxFQxZb in
oops.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

--

[Issue 18495] Integral promotion for a ~ operator

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

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

--- Comment #3 from Steven Schveighoffer  ---
Although this bug is invalid, there legitimately is a problem with the spec:
https://issues.dlang.org/show_bug.cgi?id=18496

--

[Issue 18496] New: Complement expressions now actually int promote

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

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

  Issue ID: 18496
   Summary: Complement expressions now actually int promote
   Product: D
   Version: D2
  Hardware: All
   URL: http://https://dlang.org/spec/expression.html#compleme
nt_expressions
OS: All
Status: NEW
  Keywords: spec
  Severity: normal
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: schvei...@yahoo.com

The spec for integer promotions currently says: "Note: the usual integral
promotions are not performed prior to the complement operation."

However, while this is currently true, it's a deprecation, and is NOT true with
the -transition=intpromote flag. This should be reflected in the spec.

Also, there are no notes for any of the other affected unary expressions about
integer promotion. Those should be added.

--

[Issue 18495] Integral promotion for a ~ operator

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

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schvei...@yahoo.com
 Resolution|--- |INVALID

--- Comment #2 from Steven Schveighoffer  ---
This is recent, and as designed.

Please see: https://dlang.org/changelog/2.078.0.html#fix16997

See the original bug report here:
https://issues.dlang.org/show_bug.cgi?id=16997

Note that in C:

unsigned char x = 0x80;
int y = ~x; // 0xff7f

In D, without any switches:

ubyte x = 0x80;
int y = ~x; // 0x007f

With the intpromote switch, it's the same as C. This is the point behind the
change -- it was a bug that the integer promotion didn't happen before the
complement. 

Yes, in C, you don't have to cast an int back down to unsigned char explicitly,
it just truncates without complaint. D does not. This is the difference you are
seeing that requires the cast.

--

[Issue 18495] Integral promotion for a ~ operator

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

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

--- Comment #1 from Kirill  ---
Of course if I do add "-transition=intpromote" as advised by the compiler, it
just gives an error: "cannot implicitly convert expression `~cast(int)d1` of
type `int` to `ubyte`. Fixing this requires to add some ugly looking code like
" d2 = 0xFF & ~d1; " ore something even worse like " d2 = cast(ubyte) ~d1; ".
This just can not be right.

--

[Issue 18495] New: Integral promotion for a ~ operator

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

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

  Issue ID: 18495
   Summary: Integral promotion for a ~ operator
   Product: D
   Version: D2
  Hardware: x86
OS: All
Status: NEW
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: mrkirus...@ya.ru

As far as I understand, according to the manual
(https://dlang.org/spec/expression.html#complement_expressions) the bitwise
invertion operator should give a result of the same type as of its operand. But
the code " ubyte d1 = 10; ubyte d2; d2 = ~d1; " gives a strange " Deprecation:
integral promotion not done for '~d1', use '-transition=intpromote' switch or
'~cast(int)d1' " message when compiled.

None of the C compilers I ever used had any issues with that as well. They just
compile with no warnings or errors.

The code compiles and works as expected so it is not a major issue.

--

[Issue 18491] std.experimental.logger default values after variadic template parameters

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

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

--- Comment #1 from Robert Schadek  ---
https://github.com/dlang/phobos/pull/6208

--

[Issue 13690] Interface final method which overrides a method in the parent interface leads to unimplementable interface

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

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

RazvanN  changed:

   What|Removed |Added

Summary|Curiously Recurring |Interface final method
   |Template Pattern|which overrides a method in
   ||the parent interface leads
   ||to unimplementable
   ||interface

--

[Issue 13690] Curiously Recurring Template Pattern

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

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

RazvanN  changed:

   What|Removed |Added

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

--- Comment #2 from RazvanN  ---
Running the example on dmd 2.078.0 Ubuntu 16.04 results in :

test.d(27): Error: class `test.Foo1` interface function void do_a_thing() is
not implemented
test.d(31): Error: class `test.Foo2` interface function void do_a_thing() is
not implemented
test.d(31): Error: class `test.Foo2` interface function double rotation()
@property is not implemented

So the real problem here is this: (reduced test case)

interface A
{
void x();
}

interface B : A
{
final void x() { } 
}

class C : B 
{
//override void x() {}
}

If the method in C is commented you will get error stating that you are not
implementing x. If you uncomment you will get an error stating that you cannot
override final method. That's the real bug. Changing the title to reflect that

--

[Issue 18488] test_extractor misses version(unittest) blocks, causing `Deprecation: X is not visible from Y`

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

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

Seb  changed:

   What|Removed |Added

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

--- Comment #1 from Seb  ---
It's not a bug, but a feature.

1) ALL public examples need to be runnable locally and dlang.org
That's not optional, but a deep requirement from mistakes in the past and the
resulting bad image.

2) We don't use version(unittest) for future code and are about to weed out the
last usages in Phobos, because you essentially just ended up with
- accidentally exposing a public symbol
- adding different behavior for -unittest (i.e. the testsuites) - there have
been quite a few bugs where `version(unittest) { import std.stdio;}` led to
bugs in user code because of templates and their dependence on the
version(unittest) imports which obviously wasn't caught by the testsuite.

While I really like your enthusiasm and in general a lot of things in the D
lang are old, same are quite new and have a reason for being there, so
sometimes taking a moment to step back and check why there's a CI warning (and
not directly opening a bug report + finding "workarounds") would save you save
time and frustration.

> The solution would be for test_extractor to export `vesion(unittest)` 
> declarations.

That wouldn't help and you can already do better today with a
ConditionalDeclaration visitor, e.g. in pseudo-code:

---
override void visit(const ConditionalDeclaration decl){
   // if decl is unittest
auto text = cast(immutable(char)[]) sourceCode[decl.startLocation
decl.endLocation];
}
---

--

[Issue 13693] Assertion failed at cppmangle.c:298: void CppMangleVisitor::mangle_variable(VarDeclaration*, bool)

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

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

RazvanN  changed:

   What|Removed |Added

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

--- Comment #3 from RazvanN  ---
Running the examples in comment 1 and 3 on git HEAD Ubuntu 16.04 results in the
error specified in comment 1. Looks like the assert is not hit anymore and this
looks like the correct behavior. Closing as fixed, please reopen is I am
missing something

--

[Issue 12511] static overloaded function is not accessible

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

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

RazvanN  changed:

   What|Removed |Added

 CC||an...@s-e-a-p.de

--- Comment #3 from RazvanN  ---
*** Issue 13697 has been marked as a duplicate of this issue. ***

--

[Issue 13697] Private method hides public static method

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

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

RazvanN  changed:

   What|Removed |Added

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

--- Comment #1 from RazvanN  ---
This issue has been solved. See : https://github.com/dlang/dmd/pull/7773/

*** This issue has been marked as a duplicate of issue 12511 ***

--

[Issue 18488] test_extractor misses version(unittest) blocks, causing `Deprecation: X is not visible from Y`

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

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

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com
   Hardware|x86 |All
 OS|Mac OS X|All

--

[Issue 18494] nogc ignores invariant

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

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

--- Comment #1 from FeepingCreature  ---
Reproduce:

class Class {
  invariant { new Object; }
  void foo() @nogc { }
}

void test() @nogc {
  (new Class).foo;
}

void main() { test(); }

Expected: error about gc allocation in @nogc violation

Outcome: runs silently

Further wrinkle:

void foo() @nogc in { new Object; } body { }
^ this one errors!

Either the second function should work (preferred) or the first one should also
error.

--

[Issue 18494] New: nogc ignores invariant

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

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

  Issue ID: 18494
   Summary: nogc ignores invariant
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: default_357-l...@yahoo.de

--

[Issue 18493] [betterC] Can't use aggregated type with postblit

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

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

Radu  changed:

   What|Removed |Added

   Severity|enhancement |blocker

--- Comment #1 from Radu  ---
Errors out on dmd 2.0.78.3 and dmd 2.0.79-beta1

https://run.dlang.io/is/R6BWSz

--

[Issue 18493] [betterC] Can't use aggregated type with postblit

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

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

Radu  changed:

   What|Removed |Added

   Keywords||betterC

--

[Issue 18493] New: [betterC] Can't use aggregated type with postblit

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

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

  Issue ID: 18493
   Summary: [betterC] Can't use aggregated type with postblit
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: radu.raca...@gmail.com

The following compiled with '-betterC':

=
@nogc
nothrow:

struct S
{
@nogc
nothrow:

this(this)
{
impl++;
}

~this()
{
}

int* impl;   
}

struct C
{
S s1;
S s2;
}

extern(C) int main()
{
return 0;
}
=

Produces a meaningless error (no line number no file name):

`Error: Cannot use try-catch statements with -betterC`

Commenting either the postblit ctor or dtor makes the error go away.

Expected:
To get no error.

--

[Issue 18492] New: DLang STL links are broken

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

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

  Issue ID: 18492
   Summary: DLang STL links are broken
   Product: D
   Version: D2
  Hardware: Other
OS: Other
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: arav1...@gmail.com

D's Phobos links (viewed online) like the one at std.algorithm.copy for "STL's
copy" redirects to a retirement announcement of that website. Please consider
using something similar to cplusplus.com or cppreference.com.

--

[Issue 18489] [REG 2.073]Internal error: dmd/backend/cgcod.c 1688

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

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

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

   What|Removed |Added

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

--- Comment #1 from bitter.ta...@gmx.com ---
More codegen bugs, cool.

Here's [1] the culprit, the problem is the following:
```
a is fastpar and using register XMM1
__a_8 is fastpar and using register NOREG
```

The latter _should_ be the second half of the `a' parameter, I don't know if
the NOREG is right here.

[1]
https://github.com/dlang/dmd/blob/e439e910f344359456da9bef0df2a842020831dd/src/dmd/backend/cod1.c#L4768,L4772

--

[Issue 18491] New: std.experimental.logger default values after variadic template parameters

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

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

  Issue ID: 18491
   Summary: std.experimental.logger  default values after variadic
template parameters
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: rburn...@gmail.com

changes based on
https://dlang.org/changelog/2.079.0.html#default_after_variadic

--

[Issue 18490] New: dspec_tester fails

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

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

  Issue ID: 18490
   Summary: dspec_tester fails
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: normal
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

see https://github.com/dlang/dlang.org/pull/2169#pullrequestreview-96041881 for
context

segfault on:

+$(SPEC_RUNNABLE_EXAMPLE_RUN
+---
+size_t fun(T...)(T t, string file = __FILE__)
+{
+import std.stdio;
+writeln(file, " ", t);
+return T.length;
+}
+assert(fun(1, "foo") == 2);  // not 1 (IFTI)
+assert(fun!int(1, "foo") == 1);  // IFTI
+---

--

[Issue 18489] New: [REG 2.073]Internal error: dmd/backend/cgcod.c 1688

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

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

  Issue ID: 18489
   Summary: [REG 2.073]Internal error: dmd/backend/cgcod.c 1688
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: kozz...@gmail.com

this code:

import core.simd;
double dot (double2 a, double2 b) {
double r = a.ptr[0] * b.ptr[0] + a.ptr[1] * b.ptr[1];
return r;
}

void main(){}

when compiling with -O will cause ICE

--

[Issue 18488] New: test_extractor misses version(unittest) blocks, causing `Deprecation: X is not visible from Y`

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

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

  Issue ID: 18488
   Summary: test_extractor misses version(unittest) blocks,
causing `Deprecation: X is not visible from Y`
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: normal
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

eg:

occurred in https://github.com/dlang/phobos/pull/6178

```
module bar;
vesion(unittest){
void foo(){}
}

unittest{
foo;
}
```

Deprecation: foo is not visible from bar

The solution would be for test_extractor to export `vesion(unittest)`
declarations.

This would be easy to do if
https://github.com/dlang-community/libdparse/issues/191 (Add precise source
locations (start and end) to each ASTNode #191) was fixed (at least for
declarations)

the change would be something like:

```
override void visit(const Declaration decl){

auto u2=decl.conditionalDeclaration;
if(!u2) return;
auto u3=u2.compileCondition.versionCondition;
if(!u3) return;
auto token=u3.token;
import dparse.lexer:tok;
if(token.type!=tok!"unittest") return;

foreach(ui;u2.trueDeclarations){
print(ui);  // this would need to access start and end locations of
decl
}

}


```

--

[Issue 18474] Postblit not working in shared structs

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

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

--- Comment #2 from anonymous4  ---
Some shared objects can be copied just fine like mutex itself or FILE*, but
they don't need much of postblit. And if shared postblit is unlikely to work,
you might want to @disable this(shared this) shared;

--