[Issue 14248] New: CodeView: debug info for return type of ref return function
https://issues.dlang.org/show_bug.cgi?id=14248
Issue ID: 14248
Summary: CodeView: debug info for return type of ref return
function
Product: D
Version: D2
Hardware: x86
OS: Windows
Status: NEW
Severity: enhancement
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: callumena...@gmail.com
Given:
int x;
ref int foo() { return x; }
The win32 codeview debug information for foo's type has the return type as
'int', presumably because 'ref' is a storage class which applies to the
function.
Does it make sense to propagate the refness of the function to the return type
when outputting debug info, as is done for the parameters?
--
[Issue 14198] [REG2.067a] Link failure with Variant
https://issues.dlang.org/show_bug.cgi?id=14198 --- Comment #4 from Walter Bright --- Hmm, a reference to: _D3std4conv11__T2toTAyaZ9__T2toTbZ2toFbZAya is generated, but there's a: _D3std4conv11__T2toTAyaZ9__T2toTbZ2toFNaNfbZAya in Phobos. The difference is the latter is Na (pure) and Nf (@safe). So, somehow attribute inference is happening in the latter but not the former. --
[Issue 14198] [REG2.067a] Link failure with Variant
https://issues.dlang.org/show_bug.cgi?id=14198
--- Comment #3 from Walter Bright ---
This is crazy complicated.
What's happening is in TemplateInstance::needsCodegen(), the minst for
to!string is set to std.bitmanip, which is not a root module, and so
needsCodegen() says it should be in Phobos.lib. However, std.bitmanip never
actually instantiates to!string, so it is not found in phobos.lib, and the link
fails.
_D3std4conv11__T2toTAyaZ9__T2toTbZ2toFbZAya is to!string
So, to!string's minst is being set wrong.
The wrong value is set by this code in TemplateInstance::semantic():
---
// If the first instantiation was speculative, but this is not:
if (!inst->minst)
{
// Mark it is a non-speculative instantiation.
inst->minst = minst; < here
}
---
minst is set to std.bitmanip during the evaluation of std.bitmanip.FloatRep,
which calls:
--
mixin(bitfields!(
uint, "fraction", 23,
ubyte, "exponent", 8,
bool, "sign", 1));
---
which winds up calling to!string at some point with sc->minst set to
std.bitmanip.
I don't know why to!string is not emitted when Phobos is built.
--
[Issue 14247] New: string within demangled symbol name should be made escape
https://issues.dlang.org/show_bug.cgi?id=14247
Issue ID: 14247
Summary: string within demangled symbol name should be made
escape
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: druntime
Assignee: nob...@puremagic.com
Reporter: j...@red.email.ne.jp
I wonder if I should post this as a compiler issue, because my problem is on
the profiler output.
A function template can be instantiated with string literal.
After this is demangled, inprintable characters and quotes are not cared.
Especially, line-break in a symbol name is undesirable.
-
import std.stdio;
import core.demangle;
string func(alias s)() { return s; }
void main(string[] args) {
writeln( func!"a\nb".mangleof );
writeln( demangle(func!"a\nb".mangleof) );
}
-
--
[Issue 14244] 2.067: Error when 'this' used as ref parameter
https://issues.dlang.org/show_bug.cgi?id=14244 Kenji Hara changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Kenji Hara --- *** This issue has been marked as a duplicate of issue 13934 *** --
[Issue 13934] Cannot pass 'this' to function by reference
https://issues.dlang.org/show_bug.cgi?id=13934 Kenji Hara changed: What|Removed |Added CC||dragosc...@gmail.com --- Comment #2 from Kenji Hara --- *** Issue 14244 has been marked as a duplicate of this issue. *** --
[Issue 14246] proper destruction of partially constructed objects/structs
https://issues.dlang.org/show_bug.cgi?id=14246 Ali Cehreli changed: What|Removed |Added CC||acehr...@yahoo.com --- Comment #1 from Ali Cehreli --- I think this is related: https://issues.dlang.org/show_bug.cgi?id=9704 Ali --
[Issue 14244] 2.067: Error when 'this' used as ref parameter
https://issues.dlang.org/show_bug.cgi?id=14244 safety0ff.bugz changed: What|Removed |Added CC||safety0ff.b...@gmail.com --- Comment #1 from safety0ff.bugz --- Looks like it was a bug before and fixed in 2.067. It might have been fixed as part of issue 13116. The error message should be improved (IMO.) --
[Issue 14246] New: proper destruction of partially constructed objects/structs
https://issues.dlang.org/show_bug.cgi?id=14246 Issue ID: 14246 Summary: proper destruction of partially constructed objects/structs Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: enhancement Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: schue...@gmx.net Currently, when a constructor throws, it will not call destructors of already initialized member fields. The user is responsible for catching exceptions or using `scope(failure)` and cleaning up manually. Of course, this is error prone and can easily be forgotten. I suggest to apply the same heuristic to mutable fields that is also use for tracking the initialization of immutable fields: The first "assignment" to a field must not appear in a loop or after a label, and calls the constructor instead of opAssign(). For immutable and const fields, no further writes are allowed; mutable fields can be changed as desired. At each point where an exception can occur, the compiler is then aware which fields have already been initialized, and can call their destructor. --
[Issue 14245] New: Immutable reference to immutable field in constructor allows breaking type system
https://issues.dlang.org/show_bug.cgi?id=14245
Issue ID: 14245
Summary: Immutable reference to immutable field in constructor
allows breaking type system
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: schue...@gmx.net
The spec allows immutable fields to be initialized in a constructor:
http://dlang.org/class.html#field-init
Unfortunately, it still allows taking references to them before they are
constructed. This allows breaking the type system:
struct S {
immutable int x;
this(int a) {
import std.stdio;
immutable int* b = &this.x;
writeln(*b); // prints 0
this.x = a;
writeln(*b); // prints value of a
}
}
Suggestion: Disallow taking immutable references (pointers, `ref`) before a
field's initialization. Const references are ok.
--
[Issue 14244] New: 2.067: Error when 'this' used as ref parameter
https://issues.dlang.org/show_bug.cgi?id=14244
Issue ID: 14244
Summary: 2.067: Error when 'this' used as ref parameter
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: dragosc...@gmail.com
class Foo
{
public int baz()
{
return bar(this);
}
}
public int bar(ref Foo foo)
{
return 0;
}
int main()
{
return 0;
}
2.066 compiles without error, 2.067-b3 outputs:
test.d(5) function test.bar (ref Foo foo) is not callable using argument types
(Foo).
--
[Issue 14233] [REG2.067b2] Can't build Algebraic!(This[]) anymore
https://issues.dlang.org/show_bug.cgi?id=14233 --- 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/fcc1aab7884bb460de8fce47a3a4ba5fd0e8d785 fix Issue 14233 - Can't build Algebraic!(This[]) anymore In pull#2453, VariantN.opIndex has been changed to return `Variant`. It affects to OpID.catAssign case in handler(A), because it's using `alias E = typeof((*zis)[0]);` to determine concatenated element type. https://github.com/D-Programming-Language/phobos/commit/23702b29fee08c45fcde098f6664a8277e4a5314 Merge pull request #3030 from 9rnsr/fix14233 [REG2.067b2] Issue 14233 - Can't build Algebraic!(This[]) anymore --
[Issue 14198] [REG2.067a] Link failure with Variant
https://issues.dlang.org/show_bug.cgi?id=14198
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #2 from Walter Bright ---
This reduces to:
---
import std.conv;
struct S
{
ptrdiff_t function() fptr = &handler;
static ptrdiff_t handler()
{
static if (is(typeof(to!(string)(false
{
to!(string)(false);
}
return 0;
}
}
void main()
{
}
---
I don't think it has anything to do with 4335, but with emitting instantiations
done during a typeof.
--
