[Issue 20923] Redefinition of 'size_t' is affecting TypeStruct functions
https://issues.dlang.org/show_bug.cgi?id=20923 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #2 from Dlang Bot --- @BorisCarvajal created dlang/dmd pull request #11264 "Fix Issue 20923 - Redefinition of 'size_t' is affecting TypeStruct fu…" fixing this issue: - Fix Issue 20923 - Redefinition of 'size_t' is affecting TypeStruct functions https://github.com/dlang/dmd/pull/11264 --
[Issue 20923] Redefinition of 'size_t' is affecting TypeStruct functions
https://issues.dlang.org/show_bug.cgi?id=20923 Boris Carvajal changed: What|Removed |Added CC||boris...@gmail.com Summary|Playing with types leads to |Redefinition of 'size_t' is |not detailed error message |affecting TypeStruct ||functions --- Comment #1 from Boris Carvajal --- The redefinition of size_t is affecting builtin TypeStruct functions (these don't have location info), this is clearly a bug. The code should work and you can change size_t but if you are intended to do it for this kind of methods you should be modifying object.d. --
[Issue 20923] New: Playing with types leads to not detailed error message
https://issues.dlang.org/show_bug.cgi?id=20923
Issue ID: 20923
Summary: Playing with types leads to not detailed error message
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: minor
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: feklushkin.de...@gmail.com
Code:
module app;
alias c_ulong = ulong;
extern(C)
{
alias size_t = c_ulong;
struct S
{
real not_reproduceable_without_this_variable;
}
}
Try to compile:
$ dmd -c -m32 app.d
Error: cannot implicitly convert expression h of type ulong to uint
Error message isn't contains filename and line number, but contains reference
to unknown h expression.
--
[Issue 20920] Typedef!int + Typedef!int => int? is this a typedef overlook?
https://issues.dlang.org/show_bug.cgi?id=20920 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #1 from Steven Schveighoffer --- Typedef was meant to replace the deprecated typedef feature. If you look at D1's spec https://digitalmars.com/d/1.0/type.html, it claims that if two identical typedefs are the parameters to a binary arithmetic operator, the result should be the same type. This works today with enums as well. This should be how Typedef operates. The solution may be tricky, because one has to define opBinary for the specific type, but must forward to the base type if there is no match. --
[Issue 20922] New: Cannot get frame pointer in templated member function
https://issues.dlang.org/show_bug.cgi?id=20922
Issue ID: 20922
Summary: Cannot get frame pointer in templated member function
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: simen.kja...@gmail.com
struct S {
int i;
void fun() {
// Works fine
outside!(() => i);
// inside cannot get frame pointer to S.fun.__lambda2
inside!(() => i);
}
void inside(alias fn)() {
fn();
}
}
void outside(alias fn)() {
fn();
}
It seems more than a little counterintuitive that outside() can get a frame
pointer from S.fun() while inside() cannot. I expect both to compile.
--
[Issue 20921] Cannot get frame pointer in templated static member function
https://issues.dlang.org/show_bug.cgi?id=20921 Simen Kjaeraas changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=20922 --
[Issue 20921] New: Cannot get frame pointer in templated static member function
https://issues.dlang.org/show_bug.cgi?id=20921
Issue ID: 20921
Summary: Cannot get frame pointer in templated static member
function
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: simen.kja...@gmail.com
struct S {
int i;
void fun() {
// Works fine
outside!(() => i);
// staticInside cannot access frame of function S.fun
staticInside!(() => i);
}
static void staticInside(alias fn)() {
fn();
}
}
void outside(alias fn)() {
fn();
}
Since static member functions should be equivalent to free functions, the above
clearly should compile, but as indicated by comments, it does not.
--
[Issue 20915] __traits(allMembers) results include custom version identifiers, which is unusable
https://issues.dlang.org/show_bug.cgi?id=20915 Dlang Bot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Dlang Bot --- dlang/dmd pull request #11260 "fix issue 20915 - exclude version and debug identifier from `__traits(allMembers)` results" was merged into master: - fba63812c40ba01ff0c1fd09a238233a9eff9a90 by Nils Lankila: fix issue 20915 - exclude version and debug identifier from `__traits(allMembers)` results https://github.com/dlang/dmd/pull/11260 --
