[Issue 19878] New: Some NaNs are printed as -nan
https://issues.dlang.org/show_bug.cgi?id=19878
Issue ID: 19878
Summary: Some NaNs are printed as -nan
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: and...@erdani.com
Test code:
void main() {
import std.stdio;
union X { int x; float y; }
X x;
x.x = -1;
writeln(x.y);
}
This should print "nan" but prints "-nan".
--
[Issue 19877] [dip1000] 'private' makes toHash un-@safe
https://issues.dlang.org/show_bug.cgi?id=19877
--- Comment #1 from hst...@quickfur.ath.cx ---
Here's a much more reduced case:
--
struct S {
private int _x;
}
struct RedBlackTree
{
size_t toHash() nothrow @safe
{
return .hashOf(S.init);
}
}
void main() { }
--
--
[Issue 19875] [betterC] dmd 2.0.86 Allowed class compile
https://issues.dlang.org/show_bug.cgi?id=19875 ki...@gmx.net changed: What|Removed |Added CC||ki...@gmx.net --- Comment #4 from ki...@gmx.net --- The reason for this behavior is apparently the extern(D) main function. Make that extern(C), and druntime/Phobos isn't linked. - There's a DMD special case for Windows targets, where the object file containing the D main function gets an embedded linker directive to pull in the library. --
[Issue 19877] [dip1000] 'private' makes toHash un-@safe
https://issues.dlang.org/show_bug.cgi?id=19877 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||rejects-valid Summary|'private' makes toHash |[dip1000] 'private' makes |un-@safe in |toHash un-@safe |-preview=dip1000| --
[Issue 19877] New: 'private' makes toHash un-@safe in -preview=dip1000
https://issues.dlang.org/show_bug.cgi?id=19877
Issue ID: 19877
Summary: 'private' makes toHash un-@safe in -preview=dip1000
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: hst...@quickfur.ath.cx
Code:
--
import std.container.rbtree;
alias Grid = RedBlackTree!(GridPoint);
struct GridPoint
{
private string _srcStr;
int opCmp(in GridPoint p) const { return 0; }
}
--
Compiler output (with -preview=dip1000):
--
/usr/src/d/phobos/std/container/rbtree.d(): Error: @safe function
std.container.rbtree.RedBlackTree!(GridPoint, "a < b",
false).RedBlackTree.toHash cannot call @system function
core.internal.hash.hashOf!(GridPoint).hashOf
/usr/src/d/druntime/import/core/internal/hash.d(510):
core.internal.hash.hashOf!(GridPoint).hashOf is declared here
numid.d(3): Error: template instance
`std.container.rbtree.RedBlackTree!(GridPoint, "a < b", false)` error
instantiating
--
Compiling without -preview=dip1000 works.
The problem appears to be the 'private': removing 'private' from _srcStr makes
the problem go away.
Why 'private' makes toHash un-@safe is anybody's guess.
--
[Issue 19876] New: Add Anego Studios to organizations using D
https://issues.dlang.org/show_bug.cgi?id=19876 Issue ID: 19876 Summary: Add Anego Studios to organizations using D Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: dlang.org Assignee: nob...@puremagic.com Reporter: clip...@librem.one https://github.com/anegostudios We use D for backend services and are in progress of redoing modding tools in D. --
[Issue 19875] [betterC] dmd 2.0.86 Allowed class compile
https://issues.dlang.org/show_bug.cgi?id=19875 Richard Cattermole changed: What|Removed |Added CC||alphaglosi...@gmail.com --- Comment #3 from Richard Cattermole --- The above snippet does indeed compile and run on Windows (I added the pragma). dmd is including druntime/phobos into the build automatically and has since at least 2.082. Which is providing symbols that shouldn't be available (run.dlang.org it fails on as expected). --
[Issue 19875] [betterC] dmd 2.0.86 Allowed class compile
https://issues.dlang.org/show_bug.cgi?id=19875 --- Comment #2 from joaopaulo1...@outlook.com --- (In reply to Seb from comment #1) > Why should it? > What gave you the impression that it should be? > > BetterC doesn't support class allocation (via GC) yet. > > In general, classes are a bit challenging with betterC > > Though, I recommend reading this great article: > > https://theartofmachinery.com/2018/08/13/inheritance_and_polymorphism_2.html Because D BetterC page list classes as an removed feature https://dlang.org/spec/betterc.html#consequences So, if classes are removed, why my example compiles just fine? --
[Issue 19875] [betterC] dmd 2.0.86 Allowed class compile
https://issues.dlang.org/show_bug.cgi?id=19875 Seb changed: What|Removed |Added CC||greeen...@gmail.com --- Comment #1 from Seb --- Why should it? What gave you the impression that it should be? BetterC doesn't support class allocation (via GC) yet. In general, classes are a bit challenging with betterC Though, I recommend reading this great article: https://theartofmachinery.com/2018/08/13/inheritance_and_polymorphism_2.html --
[Issue 19875] [betterC] dmd 2.0.86 Allowed class compile
https://issues.dlang.org/show_bug.cgi?id=19875 joaopaulo1...@outlook.com changed: What|Removed |Added Keywords||betterC --
[Issue 19875] New: [betterC] dmd 2.0.86 Allowed class compile
https://issues.dlang.org/show_bug.cgi?id=19875
Issue ID: 19875
Summary: [betterC] dmd 2.0.86 Allowed class compile
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: regression
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: joaopaulo1...@outlook.com
Created attachment 1745
--> https://issues.dlang.org/attachment.cgi?id=1745=edit
Compilation example
This code compiles just fine with dmd 2.0.86 and betterC enabeld
pragma(msg, __VERSION__);
import core.stdc.stdio : printf;
interface ITeste {
void some();
}
class Teste : ITeste {
void some() {
version (D_BetterC) {
printf("test\n");
}
}
}
void main() {
Teste t = new Teste();
t.some();
}
--
[Issue 10388] Compile DMD with Clang on Mac OS X
https://issues.dlang.org/show_bug.cgi?id=10388 Jacob Carlborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jacob Carlborg --- This doesn't apply anymore since DMD has been ported to D. --
[Issue 9476] Support native TLS on Mac OS X
https://issues.dlang.org/show_bug.cgi?id=9476 Jacob Carlborg changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Jacob Carlborg --- This has been implemented: https://github.com/dlang/dmd/commit/58b204f4957261ef7385c2f17a1e57fbd04169e5. --
[Issue 18893] extern(C++) class RTTI
https://issues.dlang.org/show_bug.cgi?id=18893 --- Comment #1 from Jacob Carlborg --- I would really like this as well. To be able to inspect the dynamic type in the debugger. This applies to all platforms. Seems to be a problem with LDC as well. --
[Issue 18893] extern(C++) class RTTI
https://issues.dlang.org/show_bug.cgi?id=18893 Jacob Carlborg changed: What|Removed |Added CC||d...@me.com Hardware|x86 |All OS|Windows |All --
[Issue 7517] Interface contracts broken
https://issues.dlang.org/show_bug.cgi?id=7517 Issue 7517 depends on issue 15984, which changed state. Issue 15984 Summary: [REG2.071] Interface contracts retrieve garbage instead of parameters https://issues.dlang.org/show_bug.cgi?id=15984 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 15984] [REG2.071] Interface contracts retrieve garbage instead of parameters
https://issues.dlang.org/show_bug.cgi?id=15984 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from Dlang Bot --- dlang/dmd pull request #9782 "Fix 15984 - [REG2.071] Interface contracts retrieve garbage instead of parameters" was merged into stable: - be4013b2aa1f5c7076869cbd9d1a48f3908277b6 by سليمان السهمي (Suleyman Sahmi): Fix issue 15984 - Pass parameters explicitly by ref to contract functions https://github.com/dlang/dmd/pull/9782 --
[Issue 19838] RefCounted fails to instantiate due to pureness of moveEmplace
https://issues.dlang.org/show_bug.cgi?id=19838 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @marcioapm created dlang/phobos pull request #7006 "Fix Issue 19838 - RefCounted fails to instantiate due to pureness of …" fixing this issue: - Fix Issue 19838 - RefCounted fails to instantiate due to pureness of moveEmplace https://github.com/dlang/phobos/pull/7006 --
[Issue 9029] Built-in types treated specially for alias parameters
https://issues.dlang.org/show_bug.cgi?id=9029 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Dlang Bot --- dlang/dmd pull request #9769 "Fix issue 9029: make all types (including basic) match to alias template parameters with priority MATCH.convert." was merged into master: - 3e22ae81b18d6caa57865aaa3e0d48ea6678903a by FeepingCreature: Fix issue 9029: make types match to alias template parameters with priority MATCH.convert. https://github.com/dlang/dmd/pull/9769 --
[Issue 19874] New: imported CTFE static initializers are run for no reason
https://issues.dlang.org/show_bug.cgi?id=19874
Issue ID: 19874
Summary: imported CTFE static initializers are run for no
reason
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: CTFE, performance
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: schvei...@yahoo.com
If you import a module that has a static initializer for a mutable variable
that obviously cannot be used at compile time, and that imported module isn't
being compiled, the compiler should NOT run the CTFE function, as long as it
can know the type without running it.
For example:
-
string buildModData()
{
string result;
foreach(i; 0 .. 1)
result = result ~ "lots and lots and lots of data";
return result;
}
string moddata = buildModData();
buildModData should not be run at compile time if this is simply imported,
because the compiler isn't going to store it anywhere. My system consumes 1
second to import this file, regardless if I use moddata or not.
In addition, even if the variable is type-inferred:
---
static moddata = buildModData();
---
This should still not result in CTFE execution because the type is clear from
the function definition. Essentially, only the TYPE is important here, not what
the value is, since it's not readable at compile time anyway.
I would also wish to have the value left uncalculated even if the value IS
readable at compile time, but is not used. This may be a more difficult problem
to solve, as it requires lazy evaluation of imported items.
See forum thread: https://forum.dlang.org/post/qbckmt$1oks$1...@digitalmars.com
--
[Issue 15984] [REG2.071] Interface contracts retrieve garbage instead of parameters
https://issues.dlang.org/show_bug.cgi?id=15984 --- Comment #19 from Dlang Bot --- @SSoulaimane updated dlang/dmd pull request #9782 "Fix 15984 - [REG2.071] Interface contracts retrieve garbage instead of parameters" fixing this issue: - Fix issue 15984 - Pass parameters explicitly by ref to contract functions https://github.com/dlang/dmd/pull/9782 --
