[Issue 16115] [REG2.067] Wrong code with comma operator
https://issues.dlang.org/show_bug.cgi?id=16115 --- Comment #2 from Walter Bright --- https://github.com/dlang/dmd/pull/6054 --
[Issue 14633] DDoc: false warnings for missing parameters on template declaration
https://issues.dlang.org/show_bug.cgi?id=14633 ag0ae...@gmail.com changed: What|Removed |Added CC||ag0ae...@gmail.com --- Comment #11 from ag0ae...@gmail.com --- (In reply to Lionello Lunesu from comment #1) > https://github.com/D-Programming-Language/dmd/pull/4689 With the pull request merged, can this be closed as FIXED? --
[Issue 16372] Broken links in documentation
https://issues.dlang.org/show_bug.cgi?id=16372 ag0ae...@gmail.com changed: What|Removed |Added Keywords||pull CC||ag0ae...@gmail.com Component|dlang.org |phobos Hardware|x86 |All Assignee|nob...@puremagic.com|ag0ae...@gmail.com OS|Mac OS X|All --- Comment #1 from ag0ae...@gmail.com --- https://github.com/dlang/phobos/pull/4726 --
[Issue 16381] Wrapping a float4 array leads to segfault.
https://issues.dlang.org/show_bug.cgi?id=16381 --- Comment #7 from b2.t...@gmx.com --- (In reply to b2.temp from comment #6) > (In reply to Bartek Siudeja from comment #5) > > does not help. So this seems about the return value of a function. > > Yes that's also what I said: return value == copy because float[4] doesn't > fit in a CPU register. when ref is used it's actually the address of the > first float that's returned. > > Anyway it's clearly a front-end error, because even LDC returns a run-time > error: > > > Invalid bitcast > > %63 = bitcast [4 x float] %62 to float > > LLVM ERROR: Broken function found, compilation aborted! "compile-time error" is what I really meant... --
[Issue 16381] Wrapping a float4 array leads to segfault.
https://issues.dlang.org/show_bug.cgi?id=16381 --- Comment #6 from b2.t...@gmx.com --- (In reply to Bartek Siudeja from comment #5) > does not help. So this seems about the return value of a function. Yes that's also what I said: return value == copy because float[4] doesn't fit in a CPU register. when ref is used it's actually the address of the first float that's returned. Anyway it's clearly a front-end error, because even LDC returns a run-time error: > Invalid bitcast > %63 = bitcast [4 x float] %62 to float > LLVM ERROR: Broken function found, compilation aborted! --
[Issue 16381] Wrapping a float4 array leads to segfault.
https://issues.dlang.org/show_bug.cgi?id=16381 ag0ae...@gmail.com changed: What|Removed |Added Keywords||ice CC||ag0ae...@gmail.com --
[Issue 16381] Wrapping a float4 array leads to segfault.
https://issues.dlang.org/show_bug.cgi?id=16381
--- Comment #5 from Bartek Siudeja ---
If you do know a workaround I could use, I would be really grateful.
Was checking some other options. Even changing opIndex into something like:
float4 test(size_t idx)
{
float4 temp = arr[idx];
return temp;
}
does not help. So this seems about the return value of a function.
--
[Issue 16381] Wrapping a float4 array leads to segfault.
https://issues.dlang.org/show_bug.cgi?id=16381 --- Comment #4 from b2.t...@gmx.com --- (In reply to Bartek Siudeja from comment #3) > True, but: > > My wrapper is a superclass of an abstract storage class, and not all > implementations can return a reference to float4. Another superclass looks > more or less like std.container.Array!bool, so the common interface/base > class can't use ref. I don't suggest you do to do like this. I've added the extra info for the person who'll fix it. The information added by "it works with ref" is that the copy is not valid since any access to ".ptr" leads to an AV. --
[Issue 16381] Wrapping a float4 array leads to segfault.
https://issues.dlang.org/show_bug.cgi?id=16381 --- Comment #3 from Bartek Siudeja --- True, but: My wrapper is a superclass of an abstract storage class, and not all implementations can return a reference to float4. Another superclass looks more or less like std.container.Array!bool, so the common interface/base class can't use ref. --
[Issue 16381] Wrapping a float4 array leads to segfault.
https://issues.dlang.org/show_bug.cgi?id=16381 b2.t...@gmx.com changed: What|Removed |Added Hardware|x86 |All OS|Mac OS X|All --
[Issue 16381] Wrapping a float4 array leads to segfault.
https://issues.dlang.org/show_bug.cgi?id=16381 b2.t...@gmx.com changed: What|Removed |Added CC||b2.t...@gmx.com --- Comment #2 from b2.t...@gmx.com --- If the opIndex header is changed to ref float4 opIndex(size_t idx) then no segfault. --
[Issue 16381] Wrapping a float4 array leads to segfault.
https://issues.dlang.org/show_bug.cgi?id=16381 Bartek Siudeja changed: What|Removed |Added Severity|enhancement |major --
[Issue 16381] Wrapping a float4 array leads to segfault.
https://issues.dlang.org/show_bug.cgi?id=16381 --- Comment #1 from Bartek Siudeja --- dmd: 2.068, 2.069 and 2.071 --
[Issue 16381] New: Wrapping a float4 array leads to segfault.
https://issues.dlang.org/show_bug.cgi?id=16381
Issue ID: 16381
Summary: Wrapping a float4 array leads to segfault.
Product: D
Version: D2
Hardware: x86
OS: Mac OS X
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: siu...@gmail.com
This code leads to segfault in dmd:
module test;
import std.stdio;
import core.simd;
class Array
{
float4[] arr;
this(size_t len)
{
arr = new float4[len];
}
float4 opIndex(size_t idx)
{
return arr[idx];
}
}
unittest
{
// without wrapper
auto arr = new float4[50];
float h = arr[0].ptr[0];
// with wrapper
auto arr2 = new Array(50);
assert(typeid(arr[0]) == typeid(arr2[0]));
// with intermediate
float4 f4 = arr2[0];
float f = f4.ptr[0];
// without intermediate
float g = arr2[0].ptr[0];
writeln("done");
}
Run using: dmd -main -unittest test.d
Commenting `float g` line makes the code run. Typeid also shows the same type
for arr[0] and arr2[0], but the latter can be accessed only if saved to
intermediate float4.
--
[Issue 16318] inherit from interface via abstract class
https://issues.dlang.org/show_bug.cgi?id=16318 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #5 from Steven Schveighoffer --- Requiring override for implementing interface methods is too strict. If a class defines an interface, and doesn't implement a method, compilation fails. So we don't need that warning/error. Allowing override for interfaces is fine too. Often times, one decides that an abstract class really should be an interface or vice versa. To have to go through and update all the methods to say or not say override is useless busywork. Bottom line is that pure virtual functions should allow override, and not require it, no matter what the source. In effect, since implementing is REQUIRED, override keyword is a noop. --
[Issue 2525] Can't use `override` when implementing abstract base class's interface function
https://issues.dlang.org/show_bug.cgi?id=2525 --- Comment #12 from Lodovico Giaretta --- Any news on this? People periodically hits this issue and finds it very strange... --
[Issue 16318] inherit from interface via abstract class
https://issues.dlang.org/show_bug.cgi?id=16318
--- Comment #4 from Lodovico Giaretta ---
(In reply to b2.temp from comment #3)
> (In reply to Lodovico Giaretta from comment #2)
> > If I inherit directly from an interface, I can override:
> >
> > ==
> > interface IFoo { void foo(); }
> >
> > class FooImpl: IFoo { override void foo(); } // override here is fine
>
> I suspect this usage of "override" of being an noop.
> We need an exact analysis from a DMD expert here.
If what you say is correct, that is very bad. It gives a wrong idea of what
override does really mean. See my next comment.
> > It seems counterintuitive that you can't do this transitively:
> >
> > ==
> > interface IFoo { void foo(); }
> >
> > abstract class AFoo: IFoo {}
> >
> > class FooImpl: AFoo { override void foo(); } // override here does not work
> > ==
> >
> > It is true that it works if I remove "override", but this makes it unclear
> > that FooImpl.foo overrides IFoo.foo.
>
> FooImpl.foo doesn't **override** IFoo.foo, it **implements** IFOO.foo.
>
> The compiler will throw an error if you forget. Here you argument is really
> a matter of taste. I can say that what makes unclear that IFOO is
> implemented because an abstract class is used in the middle.
Ok, I gave override a different meaning. I can accept this, but then IMO we
need a way to say "this methods implements an interface method". It is at least
as useful as "this method overrides another method", so much that I (and
probably many other programmers) conflate the two meanings into one "this
method is part of another API, not a specific feature of the current class".
--
[Issue 16380] New: no bindings for err.h
https://issues.dlang.org/show_bug.cgi?id=16380 Issue ID: 16380 Summary: no bindings for err.h Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: john.loughran.col...@gmail.com err.h isn't part of posix, but it is on (I think all) the BSDs and linux. --
[Issue 2525] Can't use `override` when implementing abstract base class's interface function
https://issues.dlang.org/show_bug.cgi?id=2525 b2.t...@gmx.com changed: What|Removed |Added CC||lodov...@giaretart.net --- Comment #11 from b2.t...@gmx.com --- *** Issue 16318 has been marked as a duplicate of this issue. *** --
[Issue 16318] inherit from interface via abstract class
https://issues.dlang.org/show_bug.cgi?id=16318
b2.t...@gmx.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #3 from b2.t...@gmx.com ---
(In reply to Lodovico Giaretta from comment #2)
> (In reply to b2.temp from comment #1)
> > Your request is not valid because it already works. You forget that an
> > interface method has to be implemented at least once before being
> > overridden, otherwise what do you override ? An interface method is not like
> > an abstract method and the error message couldn't be more accurate.
>
> Sorry, I don't understand your reasoning, so I'd love if you could answer
> the following points. Thank you in advance for spending your time on this.
>
> If I inherit directly from an interface, I can override:
>
> ==
> interface IFoo { void foo(); }
>
> class FooImpl: IFoo { override void foo(); } // override here is fine
I suspect this usage of "override" of being an noop.
We need an exact analysis from a DMD expert here.
> ==
>
> It seems counterintuitive that you can't do this transitively:
>
> ==
> interface IFoo { void foo(); }
>
> abstract class AFoo: IFoo {}
>
> class FooImpl: AFoo { override void foo(); } // override here does not work
> ==
>
> It is true that it works if I remove "override", but this makes it unclear
> that FooImpl.foo overrides IFoo.foo.
FooImpl.foo doesn't **override** IFoo.foo, it **implements** IFOO.foo.
The compiler will throw an error if you forget. Here you argument is really a
matter of taste. I can say that what makes unclear that IFOO is implemented
because an abstract class is used in the middle.
> When I encountered this, it made me
> think that FooImpl.foo was just hiding IFoo.foo because of some signature
> error I did.
Anyway, it's a DUP
*** This issue has been marked as a duplicate of issue 2525 ***
--
[Issue 15371] __traits(getMember) should bypass the protection
https://issues.dlang.org/show_bug.cgi?id=15371 Martin Nowak changed: What|Removed |Added CC||c...@dawg.eu --- Comment #6 from Martin Nowak --- (In reply to b2.temp from comment #3) > Also if a template would be instantiated in the module that use it... Well, there are plenty of reasons to not do that, foremost being that template instantiations should be independent of instantiation scope. That's why we have mixin template as an alternative. --
[Issue 15857] incorrect checkimports mismatch for overload sets
https://issues.dlang.org/show_bug.cgi?id=15857 --- Comment #11 from Jacob Carlborg --- (In reply to Martin Nowak from comment #9) > (In reply to Jacob Carlborg from comment #8) > > This is not fixed in v2.071.1-b2. > > Are you sure? The merge is in v2.071.1-b1. The issue persists with both 2.071.1 and 2.071.2-b2. The code base has gone through some major changes but I still get this error: clang/TranslationUnit.d(112,16): Deprecation: local import search method found overloadset clang.TranslationUnit.toD instead of overloadset clang.TranslationUnit.toD clang/TranslationUnit.d(266,42): Deprecation: local import search method found overloadset clang.TranslationUnit.toD instead of overloadset clang.TranslationUnit.toD clang/TranslationUnit.d(267,50): Deprecation: local import search method found overloadset clang.TranslationUnit.toD instead of overloadset clang.TranslationUnit.toD --
[Issue 16318] inherit from interface via abstract class
https://issues.dlang.org/show_bug.cgi?id=16318
--- Comment #2 from Lodovico Giaretta ---
(In reply to b2.temp from comment #1)
> Your request is not valid because it already works. You forget that an
> interface method has to be implemented at least once before being
> overridden, otherwise what do you override ? An interface method is not like
> an abstract method and the error message couldn't be more accurate.
Sorry, I don't understand your reasoning, so I'd love if you could answer the
following points. Thank you in advance for spending your time on this.
If I inherit directly from an interface, I can override:
==
interface IFoo { void foo(); }
class FooImpl: IFoo { override void foo(); } // override here is fine
==
It seems counterintuitive that you can't do this transitively:
==
interface IFoo { void foo(); }
abstract class AFoo: IFoo {}
class FooImpl: AFoo { override void foo(); } // override here does not work
==
It is true that it works if I remove "override", but this makes it unclear that
FooImpl.foo overrides IFoo.foo. When I encountered this, it made me think that
FooImpl.foo was just hiding IFoo.foo because of some signature error I did.
Also, I have an interface with *lots* of methods, and an abstract base class
that only implements a tiny portion of them. Having to explicitly enumerate the
methods that I'm not implementing bloats my code.
--
[Issue 15857] incorrect checkimports mismatch for overload sets
https://issues.dlang.org/show_bug.cgi?id=15857 --- Comment #10 from Jacob Carlborg --- (In reply to Martin Nowak from comment #9) > (In reply to Jacob Carlborg from comment #8) > > This is not fixed in v2.071.1-b2. > > Are you sure? The merge is in v2.071.1-b1. I can give it another try. --
