[Issue 18996] Inserting a struct into an std.container Array causes SIGILL(4). Illegal Instruction.
https://issues.dlang.org/show_bug.cgi?id=18996 Basile B. changed: What|Removed |Added Component|druntime|phobos --- Comment #5 from Basile B. --- Problem is confirmed: Adding `gc_init()` in the Array `shared static this()` makes the problem going away. However for now `gc_init()` is private. One way to fix the issue is make `gc_init` public in druntime and add an explicit init call in `Array`. The other would be to make a dummy alloc if `Array` element has indirections. --
[Issue 18984] Debugging stack struct's which are returned causes incorrect debuginfo.
https://issues.dlang.org/show_bug.cgi?id=18984 Rainer Schuetze changed: What|Removed |Added Keywords||pull --- Comment #3 from Rainer Schuetze --- Might not be too complicated: https://github.com/dlang/dmd/pull/8368 --
[Issue 3567] std.traits: Unqual doesn't handle arrays well
https://issues.dlang.org/show_bug.cgi?id=3567
FeepingCreature changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC||default_357-l...@yahoo.de
Resolution|INVALID |---
--- Comment #3 from FeepingCreature ---
This bug needs a second look.
Consider this code:
struct S
{
int* ipointer;
}
pragma(msg, (Unqual!(const S)).stringof);
As can be seen, Unqual has just deeply stripped const, not shallowly.
Either Unqual must be made to error when passed a const struct with reference,
or Unqual must leave const(int[]) as int[].
The current state is broken.
--
[Issue 18996] Inserting a struct into an std.container Array causes SIGILL(4). Illegal Instruction.
https://issues.dlang.org/show_bug.cgi?id=18996 --- Comment #6 from Paul Crane --- Thanks a lot for looking into this. Your fix does work for me as well. Thanks again it's much appreciated! --
[Issue 19000] Building botan library causes segfault in dsymbolsem.d
https://issues.dlang.org/show_bug.cgi?id=19000 Mike Franklin changed: What|Removed |Added CC||slavo5...@yahoo.com --- Comment #2 from Mike Franklin --- Digger blames https://github.com/dlang/dmd/pull/6995 as the offending commit. --
[Issue 18266] ICE: should allow reusing identifier in declarations in disjoint scopes in a function
https://issues.dlang.org/show_bug.cgi?id=18266 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #1 from RazvanN --- PR : https://github.com/dlang/dmd/pull/8370 --
[Issue 18026] Stack overflow in ddmd/dtemplate.d:6241, TemplateInstance::needsCodegen()
https://issues.dlang.org/show_bug.cgi?id=18026
FeepingCreature changed:
What|Removed |Added
CC||default_357-l...@yahoo.de
--- Comment #15 from FeepingCreature ---
Shorter repro:
module test;
struct FormatSpec() {}
void formatValueImpl(W, T)(W w, T obj, FormatSpec!() f) if (is(T == string)) {
}
void formatValueImpl(W, T)(W w, T val, FormatSpec!() f)
if (is(T == int))
{
import std.range : iota;
static foreach (_; iota(1000))
{
formatValueImpl!(W, string)(w, "", f);
}
}
void formatValueImpl(W, T)(W w, T obj, FormatSpec!() f) if (false) {}
void formatValueImpl(W, T)(W w, T obj, FormatSpec!() f) if (false) {}
void formatValueImpl(W, T)(W w, T obj, FormatSpec!() f) if (false) {}
void formatValueImpl(W, T)(W w, T obj, FormatSpec!() f) if (false) {}
alias fvi_Type_1 = formatValueImpl!(void function(char c), int);
alias fvi_Type_2 = formatValueImpl!(void function(const(char)[] s), int);
alias fvi_Type_3 = formatValueImpl!(void delegate(char c), int);
alias fvi_Type_4 = formatValueImpl!(void delegate(const char[]), int);
alias fvi_Type_5 = formatValueImpl!(void delegate(const(char)[] s), int);
void main() {}
Seems to happen more reliably in gdb. Since it's a stack overflow, recommended
to limit your stack size with ulimit -s 128 to test.
--
[Issue 19000] Building botan library causes segfault in dsymbolsem.d
https://issues.dlang.org/show_bug.cgi?id=19000 --- Comment #3 from Mike Franklin --- This bug report needs a dustmite reduction. It's easy to reproduce, but without a reduced test case to submit with the bug fix, this isn't going to get fixed any time soon. --
[Issue 8161] give an error for invalid property functions
https://issues.dlang.org/show_bug.cgi?id=8161 Nick Treleaven changed: What|Removed |Added Keywords||accepts-invalid --- Comment #14 from Nick Treleaven --- > 1. It affects the result of typeof (the result is the type of the return > value if @property is used, whereas it's the type of the function if > @property isn't used). This alone makes it an important feature. > The odds are very high that when Walter and Andrei finally get around to > deciding what to do with @property that they will simply decide to deprecate > it and remove it from the language That would break much code significantly due to the above feature. AIUI there is no way the current language can simulate that feature. I remind you again that this issue has nothing to do with optional parenthesis. --
[Issue 19002] New: __FUNCTION__ and __PRETTY_FUNCTION__ are not C string literals
https://issues.dlang.org/show_bug.cgi?id=19002
Issue ID: 19002
Summary: __FUNCTION__ and __PRETTY_FUNCTION__ are not C string
literals
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid, wrong-code
Severity: minor
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: schvei...@yahoo.com
void main()
{
import core.stdc.stdio;
printf(__FUNCTION__);
}
Error: function core.stdc.stdio.printf(scope const(char*) format, ...) is not
callable using argument types (string)
__FUNCTION__ should be equivalent to a string literal here. Using __FILE__ or
__MODULE__ works fine.
--
[Issue 19003] New: format!"" breaks with structs containing invariants violated in .init
https://issues.dlang.org/show_bug.cgi?id=19003
Issue ID: 19003
Summary: format!"" breaks with structs containing invariants
violated in .init
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: default_357-l...@yahoo.de
Consider this code:
module test;
import std.conv : to;
import std.format : format;
struct S
{
int i;
@disable this();
this(int i) in { assert(i > 4); } body { this.i = i; }
invariant
{
assert(i > 4);
}
string toString() { return "S("~(i.to!string)~")"; }
}
void main() {
S s = S(5);
format!"s = %s"(s);
}
It's important to remember that Type.init is not necessarily a usable instance
of S. Most importantly, you cannot safely call methods on a T.init! That is not
what T.init is for.
Nevertheless, format!"" attempts to validate its format string by calling
format("s = %s", S.init) in CTFE. format then calls S.init.toString(), which
calls its invariant, which predictably errors.
Probably, just calling format with Args.init is not the right way to validate
the format string.
--
[Issue 19004] New: Allow passing a string literal to an extern(C) variadic parameter
https://issues.dlang.org/show_bug.cgi?id=19004
Issue ID: 19004
Summary: Allow passing a string literal to an extern(C)
variadic parameter
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: n...@geany.org
A string literal usually implicitly converts to a const(char)*. This is not
considered when passing one to an extern(C) variadic parameter - due to the
literal being interpreted as a slice, which is disallowed. The string should be
implicitly cast to a pointer, as string literals are always \0-terminated. This
is handy for C string compatibility, e.g. for formatting arguments:
dmd/toobj.d:
f.error("must be `extern(C)` for `pragma(%s)`",
isCtor ? "crt_constructor".ptr : "crt_destructor".ptr);
The `.ptr` property should not be necessary.
--
[Issue 19004] Allow passing a string literal to an extern(C) variadic parameter
https://issues.dlang.org/show_bug.cgi?id=19004 Nick Treleaven changed: What|Removed |Added Keywords||pull URL||https://github.com/dlang/dm ||d/pull/8321 --
[Issue 18996] Inserting a struct into an std.container Array causes SIGILL(4). Illegal Instruction.
https://issues.dlang.org/show_bug.cgi?id=18996 Steven Schveighoffer changed: What|Removed |Added Keywords||pull CC||schvei...@yahoo.com Component|phobos |druntime Assignee|nob...@puremagic.com|schvei...@yahoo.com OS|Linux |All --- Comment #7 from Steven Schveighoffer --- The issue is that Array!string (or Array!T where T has indirections) is going to add its array as a range to the GC whenever it allocates one. What it does AFTER though is remove it's previous array as a range. When the Array has not been initialized yet, this is effectively calling GC.removeRange(null). The ProtoGC was asserting on that, generating the illegal instruction. However, the normal GC handled it just fine, which is why initializing the GC solved the problem. The ProtoGC should act exactly like the normal GC until the normal GC takes over, so this was a bug in the ProtoGC. PR: https://github.com/dlang/druntime/pull/2220 --
[Issue 3567] std.traits: Unqual doesn't handle arrays well
https://issues.dlang.org/show_bug.cgi?id=3567 Steven Schveighoffer changed: What|Removed |Added Keywords||safe CC||schvei...@yahoo.com Hardware|Other |All OS|Linux |All Severity|normal |major --- Comment #4 from Steven Schveighoffer --- This is likely going to be disruptive to fix, so many things use Unqual. But nonetheless, it's an important bug. --
[Issue 17656] Enum member circular reference error
https://issues.dlang.org/show_bug.cgi?id=17656 RazvanN changed: What|Removed |Added CC||razvan.nitu1...@gmail.com --- Comment #2 from RazvanN --- PR : https://github.com/dlang/dmd/pull/8371 --
[Issue 18996] Inserting a type containing indirections into an std.container Array causes SIGILL(4). Illegal Instruction.
https://issues.dlang.org/show_bug.cgi?id=18996 Steven Schveighoffer changed: What|Removed |Added Summary|Inserting a struct into an |Inserting a type containing |std.container Array causes |indirections into an |SIGILL(4). Illegal |std.container Array causes |Instruction.|SIGILL(4). Illegal ||Instruction. --
[Issue 8161] give an error for invalid property functions
https://issues.dlang.org/show_bug.cgi?id=8161 --- Comment #15 from Jonathan M Davis --- (In reply to Nick Treleaven from comment #14) > This alone makes it an important feature. Actually, I think that it's caused more bugs than anything - especially when much is done with type introspection. Even though a property function tries to act like a variable, it isn't one and only marginally acts like one. Being able to call a function like a variable syntactically is useful, but semantically, it really isn't one, and having the symbol effectively lie about what it is makes writing good type introspection code harder (e.g. it made it harder to figure out a way to determine whether a member was a static variable or not when we originally tried to come up with how to implement hasStaticMember). As a systems language, it really isn't possible for a function to act completely like a variable, and having the function lie about it just because it's intended to partially emulate a variable does more harm than good IMHO - especially when it really has nothing to do with whether the function can be or is used with property syntax. > That would break much code significantly due to the above feature. AIUI > there is no way the current language can simulate that feature. > > I remind you again that this issue has nothing to do with optional > parenthesis. The point is that @property is considered a mistake by Walter and Andrei and is very much in limbo. What we have is a half-baked feature that does almost nothing and whose original design has clearly been abandoned. So, trying to "fix" it without there actually being an official decision about what we're going to do with it as a whole really doesn't make much sense - especially if that involves adding any compiler warnings or errors with regards to its use. --
[Issue 18996] Inserting a type containing indirections into an std.container Array causes SIGILL(4). Illegal Instruction.
https://issues.dlang.org/show_bug.cgi?id=18996 --- Comment #8 from Paul Crane --- Thanks Steven for finding the bug and fixing it! It is appreciated! --
[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing
https://issues.dlang.org/show_bug.cgi?id=17934 Walter Bright changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --
[Issue 17934] [scope] scopeness entrypoint for unique/ref-counted missing
https://issues.dlang.org/show_bug.cgi?id=17934 Walter Bright changed: What|Removed |Added Severity|normal |enhancement --- Comment #6 from Walter Bright --- New fix: https://github.com/dlang/dmd/pull/8369 done by adding 'scope' to struct declaration. --
[Issue 18782] Documentation error: ProtectionAttributes should say Visibility Attributes
https://issues.dlang.org/show_bug.cgi?id=18782 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dlang.org https://github.com/dlang/dlang.org/commit/7c328266beac7f125bde5edc134d9fca9252e45d fix issue 18782 - Documentation error: ProtectionAttributes should say Visibility Attribute Also removing the outdated statement that visibility is not affected. Since DIP22, `private`, `public`, etc. do affect visibility. https://github.com/dlang/dlang.org/commit/78a09865cb0248edab239af41759948423ec3d90 Merge pull request #2350 from aG0aep6G/18782 fix issue 18782 - Documentation error: ProtectionAttributes should say Visibility Attribute --
[Issue 18804] std.algorithm.mutation.copy puts whole source range into target range when it should put elements
https://issues.dlang.org/show_bug.cgi?id=18804 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/19052b08de1e269bf7e8ad1fef89540a5427b5d7 fix issue 18804 - std.algorithm.mutation.copy puts whole source range into target range when it should put elements https://github.com/dlang/phobos/commit/1d70525d00ec2aa6dbbe2713531f6c9fc7e19abb Merge pull request #6485 from aG0aep6G/18804 fix issue 18804 - std.algorithm.mutation.copy puts whole source range… merged-on-behalf-of: Sebastian Wilzbach --
[Issue 18804] std.algorithm.mutation.copy puts whole source range into target range when it should put elements
https://issues.dlang.org/show_bug.cgi?id=18804 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18993] toLower is broken for UTF chars
https://issues.dlang.org/show_bug.cgi?id=18993 Seb changed: What|Removed |Added Status|NEW |RESOLVED CC||greensunn...@gmail.com Resolution|--- |FIXED --
[Issue 18933] std.range.assumeSorted should not nest SortedRange!(SortedRange!(...), pred)
https://issues.dlang.org/show_bug.cgi?id=18933 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 18933] std.range.assumeSorted should not nest SortedRange!(SortedRange!(...), pred)
https://issues.dlang.org/show_bug.cgi?id=18933 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/9112e31e501c78e94470d3485484c580192da8fd Fix Issue 18933 - std.range.assumeSorted should not nest SortedRange!(SortedRange!(...), pred) https://github.com/dlang/phobos/commit/653f382afe25852bf65ff0e73df30cac54c138f5 Merge pull request #6535 from n8sh/range-18933 Fix Issue 18933 - std.range.assumeSorted should not nest SortedRange!(SortedRange!(...), pred) merged-on-behalf-of: Sebastian Wilzbach --
[Issue 19005] New: [REG2.081-b1] object.hashOf no longer works for std.datetime.date.Date
https://issues.dlang.org/show_bug.cgi?id=19005
Issue ID: 19005
Summary: [REG2.081-b1] object.hashOf no longer works for
std.datetime.date.Date
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: regression
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: greensunn...@gmail.com
void main()
{
import std.datetime.date : Date;
Date date;
auto hash = date.hashOf;
}
--
[Issue 19005] [REG2.081-b1] object.hashOf no longer works for std.datetime.date.Date
https://issues.dlang.org/show_bug.cgi?id=19005 --- Comment #1 from Seb --- Broken by https://github.com/dlang/druntime/pull/2200 --
[Issue 19003] format!"" breaks with structs containing invariants violated in .init
https://issues.dlang.org/show_bug.cgi?id=19003 --- Comment #1 from FeepingCreature --- PR is up: https://github.com/dlang/phobos/pull/6594 --
