[Issue 24187] dmd ImportC: cmathcalls.h(55): Error: illegal type combination
https://issues.dlang.org/show_bug.cgi?id=24187 --- Comment #9 from Walter Bright --- It compiles without error if `Float32` is replaced with `float`. --
[Issue 24187] dmd ImportC: cmathcalls.h(55): Error: illegal type combination
https://issues.dlang.org/show_bug.cgi?id=24187 --- Comment #8 from Walter Bright --- The two lines: extern _Complex _Float32 cacosf32 (_Complex _Float32 __z) __attribute__ ((__nothrow__ , __leaf__)); extern _Complex _Float32 __cacosf32 (_Complex _Float32 __z) __attribute__ ((__nothrow__ , __leaf__)); extern _Complex _Float32x cacosf32x (_Complex _Float32x __z) __attribute__ ((__nothrow__ , __leaf__)); extern _Complex _Float32x __cacosf32x (_Complex _Float32x __z) __attribute__ ((__nothrow__ , __leaf__)); Thanks, this reproduces the problem. --
[Issue 20920] Typedef!int + Typedef!int => int? is this a typedef overlook?
https://issues.dlang.org/show_bug.cgi?id=20920 --- Comment #5 from mw --- wrong operation, this is for issue #24187 --
[Issue 24187] dmd ImportC: cmathcalls.h(55): Error: illegal type combination
https://issues.dlang.org/show_bug.cgi?id=24187 --- Comment #7 from mw --- Created attachment 1897 --> https://issues.dlang.org/attachment.cgi?id=1897=edit reduced to 2 lines: s2.i --
[Issue 20920] Typedef!int + Typedef!int => int? is this a typedef overlook?
https://issues.dlang.org/show_bug.cgi?id=20920 --- Comment #4 from mw --- Created attachment 1896 --> https://issues.dlang.org/attachment.cgi?id=1896=edit reduced to 2 lines: s2.i --
[Issue 24187] dmd ImportC: cmathcalls.h(55): Error: illegal type combination
https://issues.dlang.org/show_bug.cgi?id=24187 --- Comment #6 from mw --- Haha, I made it: 2 lines! $ cat s2.i extern _Complex _Float32 cacosf32 (_Complex _Float32 __z) __attribute__ ((__nothrow__ , __leaf__)); extern _Complex _Float32 __cacosf32 (_Complex _Float32 __z) __attribute__ ((__nothrow__ , __leaf__)); extern _Complex _Float32x cacosf32x (_Complex _Float32x __z) __attribute__ ((__nothrow__ , __leaf__)); extern _Complex _Float32x __cacosf32x (_Complex _Float32x __z) __attribute__ ((__nothrow__ , __leaf__)); $ gcc -c s2.i # ok $ dmd s2.i s2.i(1): Error: illegal type combination s2.i(1): Error: missing comma or semicolon after declaration of `_Float32`, found `cacosf32` instead s2.i(1): Error: illegal type combination s2.i(1): Error: missing comma or semicolon after declaration of `_Float32`, found `__cacosf32` instead s2.i(2): Error: illegal type combination s2.i(2): Error: missing comma or semicolon after declaration of `_Float32x`, found `cacosf32x` instead s2.i(2): Error: illegal type combination s2.i(2): Error: missing comma or semicolon after declaration of `_Float32x`, found `__cacosf32x` instead I will attach s2.i. But if you fix s2.i, pls also try if the fix works for s7.i.gz. --
[Issue 24193] Incorrect size of unions with bit fields
https://issues.dlang.org/show_bug.cgi?id=24193 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dlang Bot --- dlang/dmd pull request #15750 "fix Issue 24193 - Incorrect size of unions with bit fields" was merged into master: - 0f96f556335ae162673f4c0e11be0365594ba7a8 by Walter Bright: fix Issue 24193 - Incorrect size of unions with bit fields https://github.com/dlang/dmd/pull/15750 --
[Issue 24208] [DIP1000] Scope pointer can escape via non-scope parameter of pure nested function
https://issues.dlang.org/show_bug.cgi?id=24208 Paul Backus changed: What|Removed |Added Summary|[DIP1000] Nested function |[DIP1000] Scope pointer can |can pass scope pointer to |escape via non-scope |non-scope parameter |parameter of pure nested ||function --- Comment #4 from Paul Backus --- The bug is caused by an undocumented special-case language rule that allows scope pointers to be assigned to non-scope parameters of pure functions in some cases. This special case is implemented in the DMD frontend by the function TypeFunction.parameterStorageClass. In comment #1's example, `escape` is inferred to be weakly pure. As a result, TypeFunction.parameterStorageClass allows the parameter `p` to accept a scope pointer as an argument, and the error that would normally be issued by checkParamArgumentEscape is suppressed. --
[Issue 24209] New: static aa initialization of static function variable ICE
https://issues.dlang.org/show_bug.cgi?id=24209
Issue ID: 24209
Summary: static aa initialization of static function variable
ICE
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: ice, ice-on-valid-code
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: schvei...@gmail.com
CC: dkor...@live.nl
This crashes in master:
unittest {
static int[int] aa = [1: 2];
}
Full output from the compiler (note line 164 of newaa.d is where I added this
line):
```
src/core/internal/newaa.d(164): Error: internal compiler error: failed to
detect static initialization of associative array
---
ERROR: This is a compiler bug.
Please report it via https://issues.dlang.org/enter_bug.cgi
with, preferably, a reduced, reproducible example and the information below.
DustMite (https://github.com/CyberShadow/DustMite/wiki) can help with the
reduction.
---
DMD v2.105.2-311-ga8fa992a73-dirty
predefs Shared CoreUnittest DigitalMars LittleEndian D_Version2 all D_SIMD
Posix ELFv1 linux CRuntime_Glibc CppRuntime_Gcc D_InlineAsm_X86_64 X86_64
D_LP64 D_PIC unittest assert D_PreConditions D_PostConditions D_Invariants
D_ModuleInfo D_Exceptions D_TypeInfo D_HardFloat
binary../compiler/../generated/linux/release/64/dmd
version v2.105.2-311-ga8fa992a73-dirty
config
DFLAGS(none)
---
core.exception.AssertError@src/dmd/todt.d(491): Assertion failure
??:? _d_assertp [0x56181e2927d4]
src/dmd/todt.d:491 void dmd.todt.Expression_toDt(dmd.expression.Expression, ref
dmd.backend.dt.DtBuilder).visitAssocArrayLiteral(dmd.expression.AssocArrayLiteralExp)
[0x56181e15e9b9]
src/dmd/todt.d:637 _Z15Expression_toDtP10ExpressionR9DtBuilder [0x56181e15deb2]
src/dmd/todt.d:198 void dmd.todt.Initializer_toDt(dmd.init.Initializer, ref
dmd.backend.dt.DtBuilder, bool).visitExp(dmd.init.ExpInitializer)
[0x56181e15db42]
src/dmd/init.d:357 void dmd.todt.Initializer_toDt(dmd.init.Initializer, ref
dmd.backend.dt.DtBuilder, bool).visit.VisitInitializer(dmd.init.Initializer)
[0x56181e15dc2e]
src/dmd/todt.d:209 _Z16Initializer_toDtP11InitializerR9DtBuilderb
[0x56181e15d432]
src/dmd/toobj.d:874
_ZN9toObjFile9ToObjFile15initializerToDtEP14VarDeclarationR9DtBuilderb
[0x56181e166c19]
src/dmd/toobj.d:632 _ZN9toObjFile9ToObjFile5visitEP14VarDeclaration
[0x56181e16634f]
src/dmd/declaration.d:1741 _ZN14VarDeclaration6acceptEP7Visitor
[0x56181dfa26f1]
src/dmd/toobj.d:1017 _Z9toObjFileP7Dsymbolb [0x56181e16562c]
src/dmd/e2ir.d:4207 _Z14Dsymbol_toElemP7DsymbolR7IRState [0x56181e135700]
src/dmd/e2ir.d:792 dmd.backend.el.elem*
dmd.e2ir.toElem(dmd.expression.Expression, ref
dmd.toir.IRState).visitDeclaration(dmd.expression.DeclarationExp)
[0x56181e12b028]
src/dmd/e2ir.d:4157 _Z6toElemP10ExpressionR7IRState [0x56181e129d83]
src/dmd/e2ir.d:407 _Z10toElemDtorP10ExpressionR7IRState [0x56181e129405]
src/dmd/s2ir.d:690 void dmd.s2ir.Statement_toIR(dmd.statement.Statement, ref
dmd.toir.IRState,
dmd.stmtstate.StmtState!(dmd.backend.cc.block).StmtState*).visitExp(dmd.statement.ExpStatement)
[0x56181e15460c]
src/dmd/statement.d:1888 void dmd.s2ir.Statement_toIR(dmd.statement.Statement,
ref dmd.toir.IRState,
dmd.stmtstate.StmtState!(dmd.backend.cc.block).StmtState*).visit.VisitStatement(dmd.statement.Statement)
[0x56181e156bfb]
src/dmd/s2ir.d:1467 _Z14Statement_toIRP9StatementR7IRStateP9StmtStateI5blockE
[0x56181e152b9b]
src/dmd/s2ir.d:717 void dmd.s2ir.Statement_toIR(dmd.statement.Statement, ref
dmd.toir.IRState,
dmd.stmtstate.StmtState!(dmd.backend.cc.block).StmtState*).visitCompound(dmd.statement.CompoundStatement)
[0x56181e1546e7]
src/dmd/statement.d:1888 void dmd.s2ir.Statement_toIR(dmd.statement.Statement,
ref dmd.toir.IRState,
dmd.stmtstate.StmtState!(dmd.backend.cc.block).StmtState*).visit.VisitStatement(dmd.statement.Statement)
[0x56181e156c20]
src/dmd/s2ir.d:1467 _Z14Statement_toIRP9StatementR7IRStateP9StmtStateI5blockE
[0x56181e152b9b]
src/dmd/s2ir.d:717 void dmd.s2ir.Statement_toIR(dmd.statement.Statement, ref
dmd.toir.IRState,
dmd.stmtstate.StmtState!(dmd.backend.cc.block).StmtState*).visitCompound(dmd.statement.CompoundStatement)
[0x56181e1546e7]
src/dmd/statement.d:1888 void dmd.s2ir.Statement_toIR(dmd.statement.Statement,
ref dmd.toir.IRState,
dmd.stmtstate.StmtState!(dmd.backend.cc.block).StmtState*).visit.VisitStatement(dmd.statement.Statement)
[0x56181e156c20]
src/dmd/s2ir.d:1467 _Z14Statement_toIRP9StatementR7IRStateP9StmtStateI5blockE
[0x56181e152b9b]
src/dmd/s2ir.d:95 _Z14Statement_toIRP9StatementR7IRState [0x56181e152b79]
src/dmd/glue.d:1166 _Z25FuncDeclaration_toObjFileP15FuncDeclarationb
[0x56181e14bca0]
src/dmd/toobj.d:305 _ZN9toObjFile9ToObjFile5visitEP15FuncDeclaration
[0x56181e1656c5]
src/dmd/parsetimevisitor.d:61
_ZN16ParseTimeVisitorI10ASTCodegenE5visitEP19UnitTestDeclaration
[0x56181e0d6cbd]
src/dmd/func.d:4457
[Issue 24193] Incorrect size of unions with bit fields
https://issues.dlang.org/show_bug.cgi?id=24193 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #3 from Dlang Bot --- @WalterBright created dlang/dmd pull request #15750 "fix Issue 24193 - Incorrect size of unions with bit fields" fixing this issue: - fix Issue 24193 - Incorrect size of unions with bit fields https://github.com/dlang/dmd/pull/15750 --
[Issue 24193] Incorrect size of unions with bit fields
https://issues.dlang.org/show_bug.cgi?id=24193 --- Comment #2 from Walter Bright --- Not specific to C, it equally affects D. --
[Issue 24193] Incorrect size of unions with bit fields
https://issues.dlang.org/show_bug.cgi?id=24193 Walter Bright changed: What|Removed |Added Summary|A size of unions with |Incorrect size of unions |struct and bitfields is |with bit fields |incompatible with C | --
[Issue 24208] [DIP1000] Nested function can pass scope pointer to non-scope parameter
https://issues.dlang.org/show_bug.cgi?id=24208 Paul Backus changed: What|Removed |Added Summary|[DIP1000] Nested function |[DIP1000] Nested function |can escape scope parameter |can pass scope pointer to ||non-scope parameter --
[Issue 24208] [DIP1000] Nested function can escape scope parameter
https://issues.dlang.org/show_bug.cgi?id=24208 --- Comment #3 from Paul Backus --- Disregard previous example, I read the errors wrong. They occur in the function bodies, not at the call site. The parameter of `escape` is not allowed to escape at all if it is `scope`, even `return scope`. --
[Issue 24208] [DIP1000] Nested function can escape scope parameter
https://issues.dlang.org/show_bug.cgi?id=24208
--- Comment #2 from Paul Backus ---
...or maybe the problem is that it's being incorrectly inferred as `scope`
instead of `return scope`.
Another example:
---
void main() @safe
{
int* escaped;
void escape1(int* p) @safe
{
escaped = p;
}
void escape2(scope int* p) @safe
{
escaped = p;
}
void escape3(return scope int* p) @safe
{
escaped = p;
}
int n;
escape1(); // no error
escape2(); // error
escape3(); // error
}
---
It's hard to tell what attributes the compiler is inferring here, but the
observed behavior is consistent with the hypothesis that `scope int* p` is
being inferred for `escape1`, and `return scope int* p` is being inferred for
both `escape2` and `escape3`.
--
[Issue 24208] [DIP1000] Nested function can escape scope parameter
https://issues.dlang.org/show_bug.cgi?id=24208 Paul Backus changed: What|Removed |Added Summary|[DIP1000] Nested function |[DIP1000] Nested function |can pass scope pointer to |can escape scope parameter |non-scope parameter | --
[Issue 24208] [DIP1000] Nested function can pass scope pointer to non-scope parameter
https://issues.dlang.org/show_bug.cgi?id=24208
--- Comment #1 from Paul Backus ---
Actually, it turns out the second function is not necessary:
---
void main() @safe
{
int* escaped;
void escape(int* p) @safe
{
escaped = p;
}
int n;
escape();
assert(escaped == );
}
---
So, I guess the problem is either that the compiler is incorrectly inferring
`p` as `return scope`, or it's *correctly* inferring `p` as `return scope` but
failing to notice at the calls site that the "return value" has a longer
lifetime than `n`.
If it's the second case, the error should be the same one produced by this
program:
---
void main() @safe
{
int* escaped;
static void escape(ref int* ret, return scope int* p) @safe
{
ret = p;
}
int n;
escape(escaped, );
// Error: address of variable `n` assigned to `escaped`
// with longer lifetime
assert(escaped == );
}
---
--
[Issue 24208] [DIP1000] Nested function can pass scope pointer to non-scope parameter
https://issues.dlang.org/show_bug.cgi?id=24208 Paul Backus changed: What|Removed |Added Keywords||accepts-invalid, safe --
[Issue 24208] New: [DIP1000] Nested function can pass scope pointer to non-scope parameter
https://issues.dlang.org/show_bug.cgi?id=24208
Issue ID: 24208
Summary: [DIP1000] Nested function can pass scope pointer to
non-scope parameter
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: snarwin+bugzi...@gmail.com
As of DMD 2.105.2, the following invalid program compiles with -preview=dip1000
and runs without errors:
---
void main() @safe
{
int* escaped;
void escape(int* p) @safe
{
escaped = p;
}
void borrow(scope int* param) @safe
{
escape(param);
}
int n;
borrow();
assert(escaped == );
}
---
This program is invalid because, in @safe code, it assigns the address of the
variable `n` to the variable `escaped`, which has a longer lifetime than `n`.
The expression `escape(param)` should cause a compile-time error, because it
assigns the value of the scope parameter `param` to the non-scope parameter
`p`.
--
[Issue 24207] std.parallelism: AbstractTask private data is inadvertently available
https://issues.dlang.org/show_bug.cgi?id=24207 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dlang Bot --- dlang/phobos pull request #8834 "make std.parallelism.AbstractTask inaccessible" was merged into master: - 0ec4f471307251eca0b4ffe6b1969e05366a2b9b by Steven Schveighoffer: Fix issue 24207 - make AbstractTask private so it's not inadvertently accessible to users of Task. https://github.com/dlang/phobos/pull/8834 --
[Issue 23780] Manual __ctor call can mutate immutable object in @safe code
https://issues.dlang.org/show_bug.cgi?id=23780 --- Comment #2 from Paul Backus --- Unfortunately this will probably be tricky to fix, because a lot of valid code gets lowered to `obj.__ctor` internally by the DMD frontend. --
[Issue 19270] is expression fails with function types
https://issues.dlang.org/show_bug.cgi?id=19270 Basile-z changed: What|Removed |Added CC||b2.t...@gmx.com --- Comment #4 from Basile-z --- > writing a function type is only allowed as the target of an alias declaration. Yes, the reson of this restriction is that in the past the old AliasDecl syntax, i.e the one with out `=`, supported expressing a function type but not the new one. Moving the code to parse function types everywhere should be trivial but it is true that it's not much required in usual D code. --
[Issue 24207] std.parallelism: AbstractTask private data is inadvertently available
https://issues.dlang.org/show_bug.cgi?id=24207 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @schveiguy created dlang/phobos pull request #8834 "make std.parallelism.AbstractTask inaccessible" fixing this issue: - Fix issue 24207 - make AbstractTask private so it's not inadvertently accessible to users of Task. https://github.com/dlang/phobos/pull/8834 --
[Issue 24207] New: std.parallelism: AbstractTask private data is inadvertently available
https://issues.dlang.org/show_bug.cgi?id=24207 Issue ID: 24207 Summary: std.parallelism: AbstractTask private data is inadvertently available Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: major Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: schvei...@gmail.com In std.parallelism, `Task` has a "base" type `AbstractTask`, which is alias this'd to the type. However, the base is accessible because it's public (yet undocumented). It looks like it was made public to workaround an issue in the compiler, see https://github.com/dlang/phobos/commit/9d151ac1f9e45d4d57a0b74508b41b303a6a293d This should be reversed, and tested, because this allows access to the internal workings of the task system, in a completely mutable and unsafe way, including the `runTask`, the `prev` and `next` pointers, etc. Given that the original field was private, and the type itself is private and undocumented, it's clear that this was never intended to be a public interface. If this cannot be reversed, it should be redesigned so as to prevent unfettered thread-unsafe access to these fields. --
[Issue 19270] is expression fails with function types
https://issues.dlang.org/show_bug.cgi?id=19270 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #3 from Nick Treleaven --- I think `is` should support function types directly: is(typeof(foo) == int(short, double)) That might be easier to pattern match for A0. AFAICT writing a function type is only allowed as the target of an alias declaration. --
[Issue 24206] New: Can't alias a function type that returns a type with a TypeSuffix
https://issues.dlang.org/show_bug.cgi?id=24206 Issue ID: 24206 Summary: Can't alias a function type that returns a type with a TypeSuffix Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: n...@geany.org alias F = int*(); Error: function declaration without return type. (Note that constructors are always named `this`) The grammar for AliasAssignment has BasicType Parameters, and should have TypeSuffixes in between: file:///home/nick/git/dlang.org/spec/declaration.html#alias --
[Issue 24158] ImportC: enums created from string literal #defines don’t implicitly convert to const(char)* in D.
https://issues.dlang.org/show_bug.cgi?id=24158 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright --- That is probably because the C literal becomes a char[2] instead of a const(char)[2]. I'll look into that. --
[Issue 24187] dmd ImportC: cmathcalls.h(55): Error: illegal type combination
https://issues.dlang.org/show_bug.cgi?id=24187 --- Comment #5 from Walter Bright --- Thank you. What would be even more helpful would be to cut it down to just what produces the error! --
[Issue 24193] A size of unions with struct and bitfields is incompatible with C
https://issues.dlang.org/show_bug.cgi?id=24193
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #1 from Walter Bright ---
The following:
```
union U {
struct S {
int a,b;
}
S data;
int type:8;
}
pragma(msg, U.S.sizeof);
pragma(msg, U.sizeof);
```
prints:
8LU
4LU
Which is, of course, wrong. Curiously, if `int a,b;` is replaced with `long
x;`, it prints:
8LU
8LU
--
