https://issues.dlang.org/show_bug.cgi?id=8811
Iain Buclaw changed:
What|Removed |Added
Priority|P2 |P3
--
https://issues.dlang.org/show_bug.cgi?id=10959
Iain Buclaw changed:
What|Removed |Added
Priority|P2 |P3
--
https://issues.dlang.org/show_bug.cgi?id=20764
Iain Buclaw changed:
What|Removed |Added
Priority|P3 |P4
--
https://issues.dlang.org/show_bug.cgi?id=23195
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P2
--
https://issues.dlang.org/show_bug.cgi?id=16511
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P2
--
https://issues.dlang.org/show_bug.cgi?id=23113
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P2
--
https://issues.dlang.org/show_bug.cgi?id=17089
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P3
--
https://issues.dlang.org/show_bug.cgi?id=20128
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P3
--
https://issues.dlang.org/show_bug.cgi?id=23442
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P3
--
https://issues.dlang.org/show_bug.cgi?id=16338
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P3
--
https://issues.dlang.org/show_bug.cgi?id=21409
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P3
--
https://issues.dlang.org/show_bug.cgi?id=22981
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P3
--
https://issues.dlang.org/show_bug.cgi?id=21226
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P3
--
https://issues.dlang.org/show_bug.cgi?id=20206
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P3
--
https://issues.dlang.org/show_bug.cgi?id=13197
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P3
--
https://issues.dlang.org/show_bug.cgi?id=12837
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P4
--
https://issues.dlang.org/show_bug.cgi?id=16304
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P4
--
https://issues.dlang.org/show_bug.cgi?id=21588
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P4
--
https://issues.dlang.org/show_bug.cgi?id=20428
Iain Buclaw changed:
What|Removed |Added
Priority|P1 |P4
--
On Thursday, 15 December 2022 at 20:12:12 UTC, Ali Çehreli wrote:
I think this is a bug because the documentation clearly talks
about destroying the object:
OK: https://github.com/dlang/phobos/pull/8651
> do we need to do some kind of deprecation?
The behavior is so different f
On 12/15/22 11:31, Nick Treleaven wrote:
> On Wednesday, 14 December 2022 at 17:41:07 UTC, Ali Çehreli wrote:
>> I've never used Unique but I think it has a bug (or a design issue?):
>> Its destructor is the following:
>>
>> ~this()
>>
On Thursday, 15 December 2022 at 20:02:38 UTC, Nick Treleaven
wrote:
auto f() return @trusted => p ? p : v.ptr;
Whoops, that can't be @trusted unless I `assert(p)`.
On Saturday, 19 November 2022 at 15:24:33 UTC, Dukc wrote:
On Saturday, 19 November 2022 at 15:02:54 UTC, Nick Treleaven
wrote:
OK, so how do I make `lf` implicitly scope?
Have the `int*` inside it to point to a local, or assign
another `scope int*` to it.
Thanks, this works:
```d
@safe:
On Wednesday, 14 December 2022 at 17:41:07 UTC, Ali Çehreli wrote:
I've never used Unique but I think it has a bug (or a design
issue?): Its destructor is the following:
~this()
{
if (_p !is null)
{
destroy(_p);
_p = null
https://issues.dlang.org/show_bug.cgi?id=23301
Iain Buclaw changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://issues.dlang.org/show_bug.cgi?id=20428
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
On Friday, 25 November 2022 at 15:03:57 UTC, ShadoLight wrote:
I don't grok how `lf` can survive the local scope. Or am I
missing something?
Perhaps because the local scope is not pushed as a separate
(anonymous) function on the stack... if true then, yes, then
`lf` will indeed have the same
On Friday, 25 November 2022 at 17:45:57 UTC, Paul Backus wrote:
On Friday, 25 November 2022 at 14:07:28 UTC, ShadoLight wrote:
On Saturday, 19 November 2022 at 15:00:16 UTC, Paul Backus
wrote:
Since, in your example, `lf` has global lifetime, the
compiler deduces that `lf.fp` also has global
On Friday, 25 November 2022 at 14:07:28 UTC, ShadoLight wrote:
On Saturday, 19 November 2022 at 15:00:16 UTC, Paul Backus
wrote:
Since, in your example, `lf` has global lifetime, the compiler
deduces that `lf.fp` also has global lifetime, and therefore
there is nothing wrong with assigning it
On Friday, 25 November 2022 at 14:07:28 UTC, ShadoLight wrote:
On Saturday, 19 November 2022 at 14:07:59 UTC, Nick Treleaven
```d
@safe:
struct LockedFile
{
private int* fps;
auto fp() return scope => fps;
}
void main()
{
int* p;
{
auto lf = LockedFile(new int);
On Saturday, 19 November 2022 at 15:00:16 UTC, Paul Backus wrote:
On Saturday, 19 November 2022 at 14:07:59 UTC, Nick Treleaven
wrote:
Hi,
The following seems like a bug to me (reduced code, FILE*
changed to int*):
```d
@safe:
struct LockedFile
{
private int* fps;
auto fp() return
https://issues.dlang.org/show_bug.cgi?id=23195
kinke changed:
What|Removed |Added
CC||ki...@gmx.net
--- Comment #5 from kinke ---
(In
https://issues.dlang.org/show_bug.cgi?id=23195
--- Comment #4 from Walter Bright ---
(In reply to simon.vanbernem from comment #0)
> Microsoft states in their C++ x64 calling convention that structs with a
> maximum size of 8 bytes should be passed by value through registers (POD or
> not
https://issues.dlang.org/show_bug.cgi?id=23195
--- Comment #3 from Walter Bright ---
This problem appears to have been introduced by
https://github.com/dlang/dmd/pull/9434/
--
https://issues.dlang.org/show_bug.cgi?id=23195
Walter Bright changed:
What|Removed |Added
See Also||https://issues.dlang.org/sh
---
@WalterBright created dlang/dmd pull request #14651 "fix Issue 23195 - Win64
function ABI bug for small non-POD arguments" fixing this issue:
- fix Issue 23195 - Win64 function ABI bug for small non-POD arguments
https://github.com/dlang/dmd/pull/14651
--
https://issues.dlang.org/show_bug.cgi?id=23195
Walter Bright changed:
What|Removed |Added
Summary|codegen/calling convention |Win64 function ABI bug
https://issues.dlang.org/show_bug.cgi?id=23195
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #1
https://issues.dlang.org/show_bug.cgi?id=23195
ZombineDev changed:
What|Removed |Added
Keywords||backend, C++, wrong-code
CC|
On Saturday, 19 November 2022 at 15:02:54 UTC, Nick Treleaven
wrote:
On Saturday, 19 November 2022 at 14:52:23 UTC, ag0aep6g wrote:
That's essentially just a function that returns its pointer
parameter. So the program boils down to this:
```D
@safe:
int* fp(return scope int* p) { return p; }
On Saturday, 19 November 2022 at 15:02:54 UTC, Nick Treleaven
wrote:
OK, so how do I make `lf` implicitly scope?
By explicit/implicit I just meant this:
scope explicit = new int;
int x;
auto implicit =
That's probably not helping with whatever you want to accomplish.
On Saturday, 19 November 2022 at 14:52:23 UTC, ag0aep6g wrote:
That's essentially just a function that returns its pointer
parameter. So the program boils down to this:
@safe:
int* fp(return scope int* p) { return p; }
void main()
{
int* p;
{
auto lf = new int;
p =
On Saturday, 19 November 2022 at 14:07:59 UTC, Nick Treleaven
wrote:
Hi,
The following seems like a bug to me (reduced code, FILE*
changed to int*):
```d
@safe:
struct LockedFile
{
private int* fps;
auto fp() return scope => fps;
}
void main()
{
int* p;
{
auto
On 19.11.22 15:07, Nick Treleaven wrote:
Hi,
The following seems like a bug to me (reduced code, FILE* changed to int*):
```d
@safe:
struct LockedFile
{
private int* fps;
auto fp() return scope => fps;
}
void main()
{
int* p;
{
auto lf = LockedFile(new
Hi,
The following seems like a bug to me (reduced code, FILE* changed
to int*):
```d
@safe:
struct LockedFile
{
private int* fps;
auto fp() return scope => fps;
}
void main()
{
int* p;
{
auto lf = LockedFile(new int);
p = lf.fp;
}
assert(p != n
https://issues.dlang.org/show_bug.cgi?id=23454
--- Comment #3 from RazvanN ---
I don't think it's the job of the compiler spec to document the various quirks
of different CLI implementations.
--
https://issues.dlang.org/show_bug.cgi?id=23454
--- Comment #2 from Marcelo Silva Nascimento Mancini
---
Do you think that having a mention about this somewhere would be valid?
--
https://issues.dlang.org/show_bug.cgi?id=23454
RazvanN changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://issues.dlang.org/show_bug.cgi?id=23454
Issue ID: 23454
Summary: DMD CLI bug when using -I
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
On Tuesday, 1 November 2022 at 19:49:47 UTC, mw wrote:
On Tuesday, 1 November 2022 at 18:18:45 UTC, Steven
Schveighoffer wrote:
[...]
Maybe the hunt library author doesn't know. (My code does not
directly use this library, it got pulled in by some other
decencies.)
[...]
Please, if
On Tuesday, 1 November 2022 at 18:18:45 UTC, Steven Schveighoffer
wrote:
Oh yeah, isDaemon detaches the thread from the GC. Don't do
that unless you know what you are doing.
As discussed on discord, this isn't actually true. All it does is
prevent the thread from being joined before exiting
= true; // not sure if this is
related
}
}
```
in the comments, it said: "BUG: ... crashed". Looks like
someone run into this (cleanup) issue already, but unable to
fix it.
Anyway I logged an issue there:
https://github.com/huntlabs/hunt/issues/96
Oh yeah, isDaemo
On Tuesday, 1 November 2022 at 18:18:45 UTC, Steven Schveighoffer
wrote:
Oh yeah, isDaemon detaches the thread from the GC. Don't do
that unless you know what you are doing.
As discussed on discord, this isn't true actually. All it does is
prevent the thread from being joined before exiting
/source/hunt/util/DateTime.d#L430
```
class DateTime {
shared static this() {
...
dateThread.isDaemon = true; // not sure if this is related
}
}
```
in the comments, it said: "BUG: ... crashed". Looks like someone run
into this (cleanup) issue already, but una
#L430
```
class DateTime {
shared static this() {
...
dateThread.isDaemon = true; // not sure if this is related
}
}
```
in the comments, it said: "BUG: ... crashed". Looks like someone
run into this (cleanup) issue already, but unable to fix it.
Anyway I logge
On Tue, Nov 01, 2022 at 10:37:57AM -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
> On 11/1/22 10:27, H. S. Teoh wrote:
>
> > Maybe try running Digger to reduce the code for you?
>
> Did you mean dustmite, which is accessible as 'dub dustmite
> ' but I haven't used it.
Oh yes, sorry, I
On 11/1/22 10:27, H. S. Teoh wrote:
> Maybe try running Digger to reduce the code for you?
Did you mean dustmite, which is accessible as 'dub dustmite
' but I haven't used it.
My guess for the segmentation fault is that the OP is executing
destructor code that assumes some members are
On Tue, Nov 01, 2022 at 05:19:56PM +, mw via Digitalmars-d-learn wrote:
> My program received signal SIGSEGV, Segmentation fault.
>
> Its simplified structure looks like this:
>
> ```
> void foo() {
> ...
> writeln("done"); // saw this got printed!
> }
>
> int main() {
> foo();
>
ead (maybe due to foreach parallel) cleanup bug
somewhere, which is unrelated to my own code. This kind of bug is
hard to re-produce, not sure if I should file an issue.
I'm using: LDC - the LLVM D compiler (1.30.0) on x86_64.
Under gdb, here is the threads info (for the record):
Thre
https://issues.dlang.org/show_bug.cgi?id=23442
Marcelo Silva Nascimento Mancini changed:
What|Removed |Added
Summary|1 day agoDMD dll GC bug |DMD DLL GC bug when
https://issues.dlang.org/show_bug.cgi?id=23442
Issue ID: 23442
Summary: 1 day agoDMD dll GC bug when calling a function from
an interface that creates a new object
Product: D
Version: D2
Hardware: x86_64
OS
On Saturday, 24 September 2022 at 06:13:55 UTC, test123 wrote:
If so please report it for me to bugs platform. I can not
register one.
```d
package {
version(TEST) {
static:
} else {
__gshared:
}
uint test = 0;
}
```
ldmd2 -betterC -vtls -c ./test.d
On Saturday, 24 September 2022 at 06:13:55 UTC, test123 wrote:
If so please report it for me to bugs platform.
This isn't a bug, the effect of keyword: things stop at the
matching }.
(static if and version don't introduce a namespace scope, but
they still follow this rule for the { colon
On Saturday, 24 September 2022 at 07:11:12 UTC, rikki cattermole
wrote:
```d
version(all) {
__gshared:
uint test2;
}
uint test;
```
Output with -vtls:
```
Up to 2.079.1: Success with output: onlineapp.d(9): test
is thread local
Since 2.080.1: Success with output:
```d
version(all) {
__gshared:
uint test2;
}
uint test;
```
Output with -vtls:
```
Up to 2.079.1: Success with output: onlineapp.d(9): test is thread
local
Since 2.080.1: Success with output: onlineapp.d(9): `test` is
thread local
```
Looks fine to me.
If so please report it for me to bugs platform. I can not
register one.
```d
package {
version(TEST) {
static:
} else {
__gshared:
}
uint test = 0;
}
```
ldmd2 -betterC -vtls -c ./test.d
./test.d(7): `test` is thread local
Provide two functions and let the caller choose
```
void fun(ref Variant v) nothrow
{
}
void fun2(Variant v)
{
fun(v);
}
```
On Friday, 16 September 2022 at 22:43:43 UTC, frame wrote:
```d
import std.variant;
// error: destructor `std.variant.VariantN!32LU.VariantN.~this`
is not `nothrow`
void fun(Variant v) nothrow
{
}
void main()
{
fun(Variant());
}
```
A reference, pointer or slice works. I could do
On Sat, Sep 17, 2022 at 12:19:16AM +, frame via Digitalmars-d-learn wrote:
> On Friday, 16 September 2022 at 23:06:35 UTC, H. S. Teoh wrote:
>
> > Basically, if you pass something to .fun by value, then that value
> > must be destroyed by .fun once it's ready to return. So if the
> > value
On Friday, 16 September 2022 at 23:06:35 UTC, H. S. Teoh wrote:
Basically, if you pass something to .fun by value, then that
value must be destroyed by .fun once it's ready to return. So
if the value has a dtor, the dtor must be called upon exiting
from .fun. Since Variant has a throwing
On Fri, Sep 16, 2022 at 10:43:43PM +, frame via Digitalmars-d-learn wrote:
> ```d
> import std.variant;
>
> // error: destructor `std.variant.VariantN!32LU.VariantN.~this` is not
> `nothrow`
> void fun(Variant v) nothrow
> {
>
> }
>
> void main()
> {
>fun(Variant());
> }
> ```
>
> A
```d
import std.variant;
// error: destructor `std.variant.VariantN!32LU.VariantN.~this`
is not `nothrow`
void fun(Variant v) nothrow
{
}
void main()
{
fun(Variant());
}
```
A reference, pointer or slice works. I could do something on the
caller site but the signature of `fun()` should
On Thursday, 15 September 2022 at 11:33:43 UTC, Dennis wrote:
On Thursday, 15 September 2022 at 04:13:56 UTC, test123 wrote:
I hope we have github bugs.
It's being worked on.
glad to know we are move into github.
Please help me create a bug report if who has free time and
bugs account
On Thursday, 15 September 2022 at 04:13:56 UTC, test123 wrote:
I hope we have github bugs.
It's being worked on.
Please help me create a bug report if who has free time and
bugs account.
Here you go: https://issues.dlang.org/show_bug.cgi?id=23336
On Wednesday, 14 September 2022 at 14:41:38 UTC, Steven
Schveighoffer wrote:
On 9/14/22 12:53 AM, test123 wrote:
On Wednesday, 14 September 2022 at 00:40:38 UTC, Ruby The
Roobster wrote:
The addresses of items stored in memory are by definition not
constant. This isn't a bug.
If so why
On 9/14/22 12:53 AM, test123 wrote:
On Wednesday, 14 September 2022 at 00:40:38 UTC, Ruby The Roobster wrote:
The addresses of items stored in memory are by definition not
constant. This isn't a bug.
If so why this can work ?
```d
struct c { uint a, b;}
__gshared const c d = { 3, 4
On Wednesday, 14 September 2022 at 00:40:38 UTC, Ruby The
Roobster wrote:
The addresses of items stored in memory are by definition not
constant. This isn't a bug.
If so why this can work ?
```d
struct c { uint a, b;}
__gshared const c d = { 3, 4};
__gshared const e = & d;
```
the `e`
from
`const(validate_KnownRegex_enum_init_type)*` to
`const(upb_MiniTable_Enum)*` is not supported in CTFE
```
The addresses of items stored in memory are by definition not
constant. This isn't a bug.
```d
struct c { uint a, b;}
__gshared const c d = { 3, 4};
__gshared const e =
```
./test.d(4): Error: expression `(3u, 4u).a` is not a constant
I need this to work around C struct array member like this:
```c
struct c {
uint32_t a, b;
uint32_t[] arr;
}
```
If I can
---
@wolframw created dlang/phobos pull request #8552 "Fix Issue 23301 - Dlang
website (doc) bug: std_experimental_checkedint.html" fixing this issue:
- Fix Issue 23301 - Dlang website (doc) bug: std_experimental_checkedint.html
https://github.com/dlang/phobos/pull/8552
--
https://issues.dlang.org/show_bug.cgi?id=23301
RazvanN changed:
What|Removed |Added
CC||razvan.nitu1...@gmail.com
--- Comment #2 from
https://issues.dlang.org/show_bug.cgi?id=23301
--- Comment #1 from mw ---
BTW, should not these lib HTML auto generated from the D source:
https://github.com/dlang/phobos/blob/master/std/experimental/checkedint.d
Or it's manually edited?
--
https://issues.dlang.org/show_bug.cgi?id=23301
Issue ID: 23301
Summary: Dlang website (doc) bug:
std_experimental_checkedint.html
Product: D
Version: D2
Hardware: Other
OS: Linux
Status: NEW
https://issues.dlang.org/show_bug.cgi?id=5540
RazvanN changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://issues.dlang.org/show_bug.cgi?id=4558
RazvanN changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
On Friday, 22 July 2022 at 12:33:37 UTC, Anthony Quizon wrote:
I get:
```
foo.d(16): Error: mixin `foo.B.opBi!(B, ["+":function (B a, B
b) pure nothrow @nogc @safe => a])` does not match template
declaration `opBi(A, A function(A, A)[string] f0)`
```
Is this a bug or am I do
On Friday, 22 July 2022 at 12:56:44 UTC, Adam D Ruppe wrote:
```
mixin template opBi(
alias f0
) {
static foreach (k, f; f0) { typeof(this) opBinary(string op:
k)(typeof(this) r) { return f(this, r); } }
}
```
Thanks, this seems to do the trick.
Will not let me override operators on both struct A and B.
I get:
```
foo.d(16): Error: mixin `foo.B.opBi!(B, ["+":function (B a, B b) pure
nothrow @nogc @safe => a])` does not match template declaration `opBi(A,
A function(A, A)[string] f0)`
```
Is this a bug or am I doin
On Friday, 22 July 2022 at 12:33:37 UTC, Anthony Quizon wrote:
Is this a bug or am I doing something wrong?
I think this is a bug. The compiler must not take well to this
pattern, maybe the assoc array template argument, but idk. It
looks like the first type used gets cached and reused even
A and B.
I get:
```
foo.d(16): Error: mixin `foo.B.opBi!(B, ["+":function (B a, B b)
pure nothrow @nogc @safe => a])` does not match template
declaration `opBi(A, A function(A, A)[string] f0)`
```
Is this a bug or am I doing something wrong?
On Friday, 1 July 2022 at 13:44:20 UTC, Chris Katko wrote:
It appears module access to a class is broken until the
constructor finishes.
No, it has nothing to do with the module. It's the reference
itself.
Until the constructor returns, the reference through which you're
constructing the
On Friday, 1 July 2022 at 13:28:26 UTC, Chris Katko wrote:
...wait, does "world" not 'exist' until after the constructor
finishes? Is that's what's going on? But then why does it
'exist' when I send it directly? Is it only "registered" with
the module once this() finishes or something like
On Friday, 1 July 2022 at 13:12:05 UTC, Adam D Ruppe wrote:
On Friday, 1 July 2022 at 12:57:01 UTC, Chris Katko wrote:
Cannot access memory at address 0x10
Looks like an ordinary null pointer. How did you create the
variable?
D
bool initialize() //called from main
{
On Friday, 1 July 2022 at 13:20:15 UTC, Mike Parker wrote:
r.
And that also looks like the source of your original segfault.
You've got a circular reference going on in the constructors.
In other words, you're constructing a global world instance,
which in turn constructs an elf instance,
On Friday, 1 July 2022 at 13:01:30 UTC, Chris Katko wrote:
Forgot the last line. That's important because world MUST exist
by time elf is called... because world... created and called
elf.
So it's not a memory issue, but some sort of linkage issue.
world is null because the constructor
On Friday, 1 July 2022 at 12:57:01 UTC, Chris Katko wrote:
Cannot access memory at address 0x10
Looks like an ordinary null pointer. How did you create the
variable?
Forgot the last line. That's important because world MUST exist
by time elf is called... because world... created and called elf.
So it's not a memory issue, but some sort of linkage issue.
To add, I cannot even access g.world from inside elf's
constructor.
... which is the function that called it.
D
Thread 1 "main" received signal SIGSEGV, Segmentation fault.
objects.elf.this(g.pair, objects.atlasHandler) (this=, atlas=,
_pos=...) at ./src/objects.d:320
(gdb) bt
#0
dmd (but I think LDC also is affected)
this bug has bit me multiple times now, to the point I can
recognize it. Accessing module variables, from inside a method,
causes a segfault. Even if the variable should be available by
then through the call order. Proving that its a bug, you can
https://issues.dlang.org/show_bug.cgi?id=23195
Issue ID: 23195
Summary: codegen/calling convention bug causes small non-POD
arguments to be broken for extern(C++) functions
Product: D
Version: D2
Hardware: x86_64
101 - 200 of 5273 matches
Mail list logo
