[Issue 13183] C++ namespace should not conflict with import root package
https://issues.dlang.org/show_bug.cgi?id=13183
Paul O'Neil redballoo...@gmail.com changed:
What|Removed |Added
CC||redballoo...@gmail.com
--- Comment #1 from Paul O'Neil redballoo...@gmail.com ---
I'd like to add a more compelling use case:
import std.string;
extern(C++, std) { }
It's not possible to use the D standard library in the same modules as the C++
standard library.
Tested in dmd 2.066.1
--
[Issue 13976] Value range propagation to disable some slice bound tests
https://issues.dlang.org/show_bug.cgi?id=13976 Per Nordlöw per.nord...@gmail.com changed: What|Removed |Added CC||per.nord...@gmail.com --- Comment #3 from Per Nordlöw per.nord...@gmail.com --- Does this include avoiding range checking in expressions such as ```D x[0 .. $/2, $2..$] ``` which is a reoccurring pattern in D-style binary divide-and-conquer algorithms. It would be super-cool if it worked for rational variants with slice indexes in the form ```D $*p/q ``` where it can be statically proven that `p = q`. --
[Issue 13986] New: auto return for some recursive functions
https://issues.dlang.org/show_bug.cgi?id=13986
Issue ID: 13986
Summary: auto return for some recursive functions
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: bearophile_h...@eml.cc
According to Wikipedia:
http://en.wikipedia.org/wiki/C%2B%2B14#Function_return_type_deduction
C++14 is able to compile code like this:
auto correct(int i) {
if (i == 1)
return i;
else
return correct(i - 1) + i;
}
But not like this:
auto correct(int i) {
if (i != 1)
return correct(i - 1) + i;
else
return i;
}
D isn't able to compile both. Is it possible and a good idea to allow the first
function in D too?
The D spec says:
If multiple return expressions are used in the function's implementation, then
they must all deduce the same type.
--
[Issue 13987] New: Invalid struct segfaults
https://issues.dlang.org/show_bug.cgi?id=13987
Issue ID: 13987
Summary: Invalid struct segfaults
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: minor
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: erict...@gmail.com
struct S {}
S s = [{}];
causes a Segmentation fault (core dumped)
error when attempting to compile with dmd.
--
[Issue 519] Invariant not called from autogenerated class/struct constructor/destructor
https://issues.dlang.org/show_bug.cgi?id=519 --- Comment #18 from Andrei Alexandrescu and...@erdani.com --- (In reply to Martin Nowak from comment #17) (In reply to Andrei Alexandrescu from comment #16) I stated this elsewhere, just making sure I don't forget: probably we don't want to invoke invariants during the GC cycle. Walter has a different opinion on this, I don't follow his argument though. http://forum.dlang.org/post/m753hk$pt2$1...@digitalmars.com Currently it can't be done, because the calls to the invariant are embedded into the generated destructor function. Well a simple invariant would be: assert(this.parent.child is this); which would be placed in some child node, or could be moved in parent like this: assert(this.child.parent is this); The invariant involves two objects no matter where you put it. Also the invariant is called twice, before and after running the destructor. The latter forces one to perform additional cleanup, e.g. setting pointers to null. That's definitely a problem. Invariants are not supposed to hold after destruction. --
[Issue 13988] New: simplify/cleanup rt.lifetime
https://issues.dlang.org/show_bug.cgi?id=13988 Issue ID: 13988 Summary: simplify/cleanup rt.lifetime Product: D Version: unspecified Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: c...@dawg.eu The module suffers a lot from bad code. It's mildly complex but due to missing abstractions/separations the complexity is spread throughout code of completely different concerns. This makes it hard to change/review so people tend to stuff new code into the existing mess. 3 concrete points: Reduce code duplication for different branches that simply handle different array lengths. Turn the implicit smallpad, medpad, largepad layouts into structs and use those (combined with casts) to avoid all the void* arithmetic. Turn the block info cache into a struct. --
[Issue 13989] New: add system-specific ext to -of parameter if ext is invalid
https://issues.dlang.org/show_bug.cgi?id=13989 Issue ID: 13989 Summary: add system-specific ext to -of parameter if ext is invalid Product: D Version: D2 Hardware: x86 OS: All Status: NEW Severity: enhancement Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: bb.t...@gmx.com consider the following cases: 1) dmd myfile.d -ofprogram DMD produces the file program.exe 2) dmd myfile.d -ofprogram.exe DMD produces the file program.exe 3) dmd myfile.d -ofprogram.cool DMD produces the file program.cool 4) dmd myfile.d -ofprogram.cool.exe DMD produces the file program.cool.exe In the third case, DMD should produce the file program.cool.exe Currently it seems that DMD looks for any extension and doesn't add one if a dot is found. However a filename can include many dots, it's a legal syntax. DMD should compare the extension found with the one expected (according to the other switches, such as -lib) and then add the expected one if they are different. --
[Issue 13989] add system-specific ext to -of parameter if ext is invalid
https://issues.dlang.org/show_bug.cgi?id=13989 Orvid King blah38...@gmail.com changed: What|Removed |Added CC||blah38...@gmail.com --- Comment #1 from Orvid King blah38...@gmail.com --- I disagree with this, it is perfectly reasonable to want to output a file with a non-standard extension, many plugin mechanisms for instance use a file extension other than .dll. I believe it is the user's issue if they want to output a file with an extension of .cool. --
[Issue 13989] add system-specific ext to -of parameter if ext is invalid
https://issues.dlang.org/show_bug.cgi?id=13989 Orvid King blah38...@gmail.com changed: What|Removed |Added Hardware|x86 |All --
[Issue 12943] Duplicated error message for out of bound array index
https://issues.dlang.org/show_bug.cgi?id=12943 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Kenji Hara k.hara...@gmail.com --- *** This issue has been marked as a duplicate of issue 10910 *** --
[Issue 10910] Duplicate error messages for array bounds errors
https://issues.dlang.org/show_bug.cgi?id=10910 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #2 from Kenji Hara k.hara...@gmail.com --- *** Issue 12943 has been marked as a duplicate of this issue. *** --
[Issue 7514] [e2ir] Error in e2ir at dynamic array to static array cast
https://issues.dlang.org/show_bug.cgi?id=7514 --- Comment #11 from bearophile_h...@eml.cc --- (In reply to Kenji Hara from comment #10) I think the cast from int[] to int[2][1] should not be accepted. Can you please explain why? Currently this is accepted: int[2] m = cast(int[2])[1, 2]; --
[Issue 519] Invariant not called from autogenerated class/struct constructor/destructor
https://issues.dlang.org/show_bug.cgi?id=519 --- Comment #17 from Martin Nowak c...@dawg.eu --- (In reply to Andrei Alexandrescu from comment #16) I stated this elsewhere, just making sure I don't forget: probably we don't want to invoke invariants during the GC cycle. Walter has a different opinion on this, I don't follow his argument though. http://forum.dlang.org/post/m753hk$pt2$1...@digitalmars.com Currently it can't be done, because the calls to the invariant are embedded into the generated destructor function. Also the invariant is called twice, before and after running the destructor. The latter forces one to perform additional cleanup, e.g. setting pointers to null. --
[Issue 2834] Struct Destructors are not called by the GC, but called on explicit delete.
https://issues.dlang.org/show_bug.cgi?id=2834 --- Comment #30 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/dbbea7c5bd4d8936dc8cb523b65f771842f2a487 Merge pull request #864 from Orvid/structDestructors Fix Issue 2834 - The GC will now call destructors on heap allocated structs --
[Issue 5570] 64 bit C ABI not followed for passing structs and complex numbers as function parameters
https://issues.dlang.org/show_bug.cgi?id=5570 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #49 from yebblies yebbl...@gmail.com --- These other bug reports are part of this: Issue 13955 - 64 bit C ABI not followed for passing structs with mixed floating types Issue 13956 - 64 bit C ABI not followed for passing empty structs Issue 13957 - 64 bit C ABI not followed for passing structs with floating+integer types And issue 13955 and issue 13956 have been fixed in master. (In reply to Martin Nowak from comment #47) What's still left for this issue and why is there so much ABI dependent code in the frontend? Most of the remaining issues are in the code generator, and quite difficult to fix. --
[Issue 2834] Struct Destructors are not called by the GC, but called on explicit delete.
https://issues.dlang.org/show_bug.cgi?id=2834 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13984] New: Mangling of /ENTRY depends on DLL imports
https://issues.dlang.org/show_bug.cgi?id=13984
Issue ID: 13984
Summary: Mangling of /ENTRY depends on DLL imports
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Keywords: link-failure
Severity: normal
Priority: P1
Component: Optlink
Assignee: nob...@puremagic.com
Reporter: thecybersha...@gmail.com
/ test.d
extern(System) uint GetVersion();
void main()
{
//GetVersion();
}
/
This program compiles and links fine with the command:
dmd -L/ENTRY:_mainCRTStartup test.d
However, if you uncomment the GetVersion line, linking breaks:
OPTLINK (R) for Win32 Release 8.00.15
Copyright (C) Digital Mars 1989-2013 All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
OPTLINK : Error 180: No Match Found for Export/ENTRY - : _mainCRTStartup
--- errorlevel 1
To fix linking, the leading underscore needs to be removed from the command
line:
dmd -L/ENTRY:mainCRTStartup test.d
--
[Issue 13985] New: Wrong code when using super to call final interface method
https://issues.dlang.org/show_bug.cgi?id=13985
Issue ID: 13985
Summary: Wrong code when using super to call final interface
method
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: wrong-code
Severity: critical
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: thecybersha...@gmail.com
/// test.d ///
interface I
{
void m1();
void m2();
void m3();
final void mf()
{
m3();
}
}
class C1 : I
{
void m1() {}
void m2() {}
void m3() {}
}
class C2 : C1
{
void ml()
{
super.mf();
}
}
void main()
{
auto l = new C2();
l.ml();
}
//
This program throws the exception:
object.Exception@src\object_.d(100): need opCmp for class test.C2
--
[Issue 13980] We need better documentation for potential contributors
https://issues.dlang.org/show_bug.cgi?id=13980 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added Hardware|x86 |All OS|Mac OS X|All --
