[Issue 5270] Using a scope delegate allows memory corruption in safe mode
https://issues.dlang.org/show_bug.cgi?id=5270 Mike changed: What|Removed |Added CC||slavo5...@yahoo.com --
[Issue 13095] Sometimes struct destructor is called if constructor throws
https://issues.dlang.org/show_bug.cgi?id=13095 --- Comment #2 from Walter Bright --- https://github.com/D-Programming-Language/dmd/pull/4101 --
[Issue 13095] Sometimes struct destructor is called if constructor throws
https://issues.dlang.org/show_bug.cgi?id=13095 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com Summary|Someteims `struct` |Sometimes struct destructor |destructor is called if |is called if constructor |constructor throws |throws --
[Issue 8304] writeln of empty Nullables too
https://issues.dlang.org/show_bug.cgi?id=8304 --- Comment #6 from bearophile_h...@eml.cc --- *** Issue 10915 has been marked as a duplicate of this issue. *** --
[Issue 10915] std.typecons.Nullable throws in writeln() if it's null
https://issues.dlang.org/show_bug.cgi?id=10915 bearophile_h...@eml.cc changed: What|Removed |Added Status|RESOLVED|CLOSED Resolution|FIXED |DUPLICATE --- Comment #7 from bearophile_h...@eml.cc --- *** This issue has been marked as a duplicate of issue 8304 *** --
[Issue 10915] std.typecons.Nullable throws in writeln() if it's null
https://issues.dlang.org/show_bug.cgi?id=10915 --- Comment #6 from bearophile_h...@eml.cc --- (In reply to github-bugzilla from comment #5) > Commits pushed to master at https://github.com/D-Programming-Language/phobos > > https://github.com/D-Programming-Language/phobos/commit/ > 2c8fdeb0b0f92c24c4ffa26a4beca6bcd9a5c0ba > Fix Issue 10915 - std.typecons.Nullable throws in writeln() if it's null > > https://github.com/D-Programming-Language/phobos/commit/ > 2e58214d1d3feee582ca639edf7c5e2af8db365b > Merge pull request #2587 from MetaLang/nullable-tostring > > Fix Issue 10915 - std.typecons.Nullable throws in writeln() if it's null Answered in Issue 8303 . --
[Issue 8304] writeln of empty Nullables too
https://issues.dlang.org/show_bug.cgi?id=8304
--- Comment #5 from bearophile_h...@eml.cc ---
This has improved the situation:
https://github.com/D-Programming-Language/phobos/pull/2587
But the example in comment #1 still fails:
void main() {
import std.stdio: writeln;
import std.typecons: Nullable;
const(Nullable!int) c;
writeln(c);
}
core.exception.AssertError@C:\dmd2\src\phobos\std\typecons.d(1529): Called
`get' on null Nullable!int.
--
[Issue 12969] std.json: Lack of opIndexAssign operator for JSONValue may become a source of runtime errors
https://issues.dlang.org/show_bug.cgi?id=12969 github-bugzi...@puremagic.com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --
[Issue 12969] std.json: Lack of opIndexAssign operator for JSONValue may become a source of runtime errors
https://issues.dlang.org/show_bug.cgi?id=12969 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/f2bc851d7c16bfc242dff4c680cf5a24f47cf020 std.json: Fixed issue 12969. opIndexAssign operator for JSONValue added. Changed order of elements in enum JSON_TYPE so NULL is a default type when JSONValue is not initialized Signed-off-by: Uranuz https://github.com/D-Programming-Language/phobos/commit/7dfe2885763801a1d8339243cdc61b3caf9d0cdf Merge pull request #2607 from Dicebot/uranuz_issue_12969 Fix issue 12969 : opIndexAssign operator for JSONValue --
[Issue 13594] std.algorithm.nextPermutation should accept ranges of lvalues
https://issues.dlang.org/show_bug.cgi?id=13594 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com Summary|std.algorithm.nextPermutati |std.algorithm.nextPermutati |on for fixed size arrays|on should accept ranges of |too |lvalues Severity|enhancement |normal --- Comment #4 from Steven Schveighoffer --- I'm changing the requirements. Bearophile's second attempt with the slice operator should compile. There is no need to require the range itself to be an lvalue, just that its elements are lvalues. I also consider it a bug that this isn't the case. --
[Issue 13661] static array init does not call destructors
https://issues.dlang.org/show_bug.cgi?id=13661 Kenji Hara changed: What|Removed |Added Keywords||patch, wrong-code Hardware|x86_64 |All OS|Linux |All Severity|normal |major --- Comment #2 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/4100 https://github.com/D-Programming-Language/druntime/pull/1006 --
[Issue 10915] std.typecons.Nullable throws in writeln() if it's null
https://issues.dlang.org/show_bug.cgi?id=10915 --- Comment #5 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/2c8fdeb0b0f92c24c4ffa26a4beca6bcd9a5c0ba Fix Issue 10915 - std.typecons.Nullable throws in writeln() if it's null https://github.com/D-Programming-Language/phobos/commit/2e58214d1d3feee582ca639edf7c5e2af8db365b Merge pull request #2587 from MetaLang/nullable-tostring Fix Issue 10915 - std.typecons.Nullable throws in writeln() if it's null --
[Issue 10915] std.typecons.Nullable throws in writeln() if it's null
https://issues.dlang.org/show_bug.cgi?id=10915 github-bugzi...@puremagic.com changed: What|Removed |Added Resolution|DUPLICATE |FIXED --
[Issue 10528] Private constant (enum) properties not private
https://issues.dlang.org/show_bug.cgi?id=10528
murphyslaw...@gmail.com changed:
What|Removed |Added
CC||murphyslaw...@gmail.com
--- Comment #3 from murphyslaw...@gmail.com ---
Confirmed on DMD 2.066.0-1 on Linux. It also fails to catch the error inside an
anonymous enum aggregate.
If I declare ModuleData as:
private enum { ModuleData = "asdfgh" }
it also slips by the compiler without error.
--
[Issue 13666] Undefined Symbols for __gshared data symbols in templates
https://issues.dlang.org/show_bug.cgi?id=13666 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13666] Undefined Symbols for __gshared data symbols in templates
https://issues.dlang.org/show_bug.cgi?id=13666 --- Comment #3 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/fbec2df168658b64ea699c3cbbad5d73df5e310e Merge pull request #4099 from rainers/issue_13666 Fix issue 13666: Undefined Symbols for __gshared data symbols in templates --
[Issue 13668] [ICE] unable to compile __traits(allMembers...)
https://issues.dlang.org/show_bug.cgi?id=13668 Misu changed: What|Removed |Added Keywords||ice --
[Issue 13668] New: [ICE] unable to compile __traits(allMembers...)
https://issues.dlang.org/show_bug.cgi?id=13668
Issue ID: 13668
Summary: [ICE] unable to compile __traits(allMembers...)
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: misugi-p...@live.fr
This code gives me a segmentation fault with dmd 2.066 and 2.065
import std.stdio;
class User : Entity!User
{
int id;
}
class Entity(T)
{
pragma(msg, generateProperties!(T));
}
template generateProperties(alias To)
{
string getProperties(alias Ta)()
{
import std.string : capitalize;
string toRet = "";
// This line is bad
pragma(msg, __traits(allMembers, Ta));
return toRet;
}
enum generateProperties = getProperties!(To);
}
void main() { }
--
[Issue 13667] ICE with inout and alias this
https://issues.dlang.org/show_bug.cgi?id=13667 Martin Nowak changed: What|Removed |Added Keywords|ice-on-invalid-code |ice --
[Issue 13667] New: ICE with inout and alias this
https://issues.dlang.org/show_bug.cgi?id=13667
Issue ID: 13667
Summary: ICE with inout and alias this
Product: D
Version: unspecified
Hardware: x86_64
OS: Linux
Status: NEW
Keywords: ice-on-invalid-code
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: c...@dawg.eu
cat > bug.d << CODE
struct Array(T)
{
Array!(T) impConv() const { return *cast(typeof(return)*)this; }
alias impConv this;
struct Range
{
Array _arr;
void front() inout { _arr[]; }
}
}
alias AI = Array!int;
CODE
dmd -c bug
--
[Issue 9655] Two functions with identical implementations are allowed to have the same address
https://issues.dlang.org/show_bug.cgi?id=9655 --- Comment #12 from Steven Schveighoffer --- (In reply to Steven Schveighoffer from comment #11) > I don't think this is true. I was supposed to delete this part of the comment, when I found the spec quote. Sorry :) --
[Issue 9655] Two functions with identical implementations are allowed to have the same address
https://issues.dlang.org/show_bug.cgi?id=9655 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #11 from Steven Schveighoffer --- (In reply to bearophile_hugs from comment #9) > Why? I think the C standard requires those functions to have different > addresses. I don't think this is true. (In reply to bearophile_hugs from comment #9) > (In reply to yebblies from comment #7) > > > No, you shouldn't rely on this ever. > > Why? I think the C standard requires those functions to have different > addresses. So I think that C code is correct. (And indeed as far as I know > GCC replaces equal function implementations with a jump, to keep addressed > distinct). >From the C standard: Two pointers compare equal if and only if both are null pointers, both are pointers to the same object (including a pointer to an object and a subobject at its beginning) or function, both are pointers to one past the last element of the same array object, or one is a pointer to one past the end of one array object and the other is a pointer to the start of a different array object that happens to immediately follow the first array object in the address space. So it appears, from the "if and only if", that bearophile is right. But D does not have to follow C rules. Even if we define an extern(C) function in D, it does not mean we have to follow those rules. I would say the issues that might occur because of this change are astronomically small. Consider that a piece of code that depends on distinct functions having distinct addresses may still work just fine even with ICF. However, it should be noted on the spec that we deviate from those requirements. It currently does not address this point from what I could find. --
[Issue 9655] Two functions with identical implementations are allowed to have the same address
https://issues.dlang.org/show_bug.cgi?id=9655 --- Comment #10 from yebblies --- (In reply to bearophile_hugs from comment #9) > (In reply to yebblies from comment #7) > > > No, you shouldn't rely on this ever. > > Why? Because in D it's specified that the functions may not have distinct addresses. > I think the C standard requires those functions to have different > addresses. So I think that C code is correct. (And indeed as far as I know > GCC replaces equal function implementations with a jump, to keep addressed > distinct). In a language without templates, code folding is much less useful. --
[Issue 9655] Two functions with identical implementations are allowed to have the same address
https://issues.dlang.org/show_bug.cgi?id=9655 --- Comment #9 from bearophile_h...@eml.cc --- (In reply to yebblies from comment #7) > No, you shouldn't rely on this ever. Why? I think the C standard requires those functions to have different addresses. So I think that C code is correct. (And indeed as far as I know GCC replaces equal function implementations with a jump, to keep addressed distinct). --
[Issue 13666] Undefined Symbols for __gshared data symbols in templates
https://issues.dlang.org/show_bug.cgi?id=13666 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #2 from Steven Schveighoffer --- Very similar issue encountered: https://github.com/D-Programming-Language/druntime/pull/990 Fails on only OSX and Windows. Error is a undefined symbol, just like this. In my case, the same code, compiled without -inline, succeeds to build. Seems different for your case. --
[Issue 5995] string append negative integer causes segfault
https://issues.dlang.org/show_bug.cgi?id=5995 --- Comment #12 from Steven Schveighoffer --- (In reply to hsteoh from comment #11) > Should appending invalid codepoints append the Unicode replacement character > instead? I think implicit casting of int to dchar should be invalid altogether. See my 2011 comment. --
[Issue 9655] Two functions with identical implementations are allowed to have the same address
https://issues.dlang.org/show_bug.cgi?id=9655 Ketmar Dark changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --- Comment #8 from Ketmar Dark --- (In reply to bearophile_hugs from comment #6) > This is not enough. What do you have to do if you want to be certain to have > distinct D functions pointers even if the function body may or may not be > the same? (There is C code out there that relies on this guaranteed, like > some evolutionary algorithm that breeds functions). Are D functions tagged > with extern(C) exempt from this optimization? that code is foobared. please, don't use it. --
[Issue 9655] Two functions with identical implementations are allowed to have the same address
https://issues.dlang.org/show_bug.cgi?id=9655 --- Comment #7 from yebblies --- (In reply to bearophile_hugs from comment #6) > > This is not enough. What do you have to do if you want to be certain to have > distinct D functions pointers even if the function body may or may not be > the same? (There is C code out there that relies on this guaranteed, like > some evolutionary algorithm that breeds functions). Are D functions tagged > with extern(C) exempt from this optimization? No, you shouldn't rely on this ever. --
[Issue 9655] Two functions with identical implementations are allowed to have the same address
https://issues.dlang.org/show_bug.cgi?id=9655 --- Comment #6 from bearophile_h...@eml.cc --- (In reply to github-bugzilla from comment #5) > Commit pushed to master at > https://github.com/D-Programming-Language/dlang.org > > https://github.com/D-Programming-Language/dlang.org/commit/ > e5d39c811d080ad8aae8903e96711f7f7715ca99 > Merge pull request #684 from quickfur/issue9655 > > Issue 9655: Functions with identical bodies are allowed to be merged by > compiler. This is not enough. What do you have to do if you want to be certain to have distinct D functions pointers even if the function body may or may not be the same? (There is C code out there that relies on this guaranteed, like some evolutionary algorithm that breeds functions). Are D functions tagged with extern(C) exempt from this optimization? --
[Issue 13381] Two cases of array literal that can be stack-allocated
https://issues.dlang.org/show_bug.cgi?id=13381
--- Comment #15 from bearophile_h...@eml.cc ---
Another common case where I'd like the compiler to avoid GC-allocations:
void main() @nogc {
immutable int[4] a1 = [1, 2, 4, 5];
size_t i = 2;
immutable int[5] a2 = a1[0 .. i] ~ 3 ~ a1[i .. $];
}
Currently you have to write this more bug-prone code and the 'a2' variable
can't be immutable:
void main() @nogc {
immutable int[4] a1 = [1, 2, 4, 5];
size_t i = 2;
int[5] a2 = void;
a2[0 .. i] = a1[0 .. i];
a2[2] = 3;
a2[i + 1 .. $] = a1[i .. $];
}
--
[Issue 13666] Undefined Symbols for __gshared data symbols in templates
https://issues.dlang.org/show_bug.cgi?id=13666 Rainer Schuetze changed: What|Removed |Added Keywords||link-failure, pull --- Comment #1 from Rainer Schuetze --- https://github.com/D-Programming-Language/dmd/pull/4099 --
[Issue 12754] MAC link error for template to static value
https://issues.dlang.org/show_bug.cgi?id=12754 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #12 from Rainer Schuetze --- This might be related: https://issues.dlang.org/show_bug.cgi?id=13666 --
[Issue 9655] Two functions with identical implementations are allowed to have the same address
https://issues.dlang.org/show_bug.cgi?id=9655 --- Comment #5 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/e5d39c811d080ad8aae8903e96711f7f7715ca99 Merge pull request #684 from quickfur/issue9655 Issue 9655: Functions with identical bodies are allowed to be merged by compiler. --
