Thread overview | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
January 19, 2018 [Issue 18269] Inconsistent of delegate @system attribute | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=18269 --- Comment #1 from hsteoh@quickfur.ath.cx --- P.S. This is a blocker for Phobos PR: https://github.com/dlang/phobos/pull/5797 -- |
January 19, 2018 [Issue 18269] Inconsistent string representation of delegate @system attribute | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=18269 hsteoh@quickfur.ath.cx changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Inconsistent of delegate |Inconsistent string |@system attribute |representation of delegate | |@system attribute -- |
January 24, 2018 [Issue 18269] Inconsistent string representation of delegate @system attribute | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=18269 --- Comment #2 from hsteoh@quickfur.ath.cx --- Reduced further: ----------- void one(T)(T t, size_t ln = 0) { pragma(msg, "one: ", T.stringof); two(t); } void two(T)(T t) { pragma(msg, "two: ", T.stringof); } alias T = void delegate(); void main() { void func() @system { __gshared int x; ++x; throw new Exception(""); } one(&func); } ----------- Commenting out the `alias T` line makes the problem go away. Current investigation seems to be pointing to an ambiguity in the string table. Still investigating further to narrow the problem down further. -- |
January 13, 2020 [Issue 18269] Inconsistent string representation of delegate @system attribute | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=18269 Steven Schveighoffer <schveiguy@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schveiguy@yahoo.com --- Comment #3 from Steven Schveighoffer <schveiguy@yahoo.com> --- Is this literally just the string representation of a delegate type that is wrong? I mean, I tried this out on the latest compiler, and trying to *call* t in `two` and trying to apply a @safe tag to it makes it fail to compile. -- |
June 19, 2020 [Issue 18269] Inconsistent string representation of delegate @system attribute | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=18269 Paul Backus <snarwin+bugzilla@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |snarwin+bugzilla@gmail.com --- Comment #4 from Paul Backus <snarwin+bugzilla@gmail.com> --- Possibly related to issue 20878 and issue 3796. -- |
August 13, 2020 [Issue 18269] Inconsistent string representation of delegate @system attribute | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=18269 --- Comment #5 from hsteoh@quickfur.ath.cx --- Also blocking this PR: https://github.com/dlang/phobos/pull/7556 -- |
August 13, 2020 [Issue 18269] Inconsistent string representation of delegate @system attribute | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=18269 --- Comment #6 from hsteoh@quickfur.ath.cx --- (In reply to Steven Schveighoffer from comment #3) > Is this literally just the string representation of a delegate type that is wrong? I mean, I tried this out on the latest compiler, and trying to *call* t in `two` and trying to apply a @safe tag to it makes it fail to compile. Looks like just the string representation is wrong. Not the end of the world, but there *is* a unittest in std.format that checks for the string representation, and this bug is causing failures completely unrelated to the PR, and it's rather frustrating. -- |
August 14, 2020 [Issue 18269] Inconsistent string representation of delegate @system attribute | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=18269 Boris Carvajal <boris2.9@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |boris2.9@gmail.com --- Comment #7 from Boris Carvajal <boris2.9@gmail.com> --- I checked the issue a few months ago, this is what I recall. The problem here is that both 'void delegate()' and 'void delegate() @system' are mangled in the same way because @system isn't coded in the mangle system (it's the same as a function without attributes), so the types are identical to any compiler comparison and that includes template instantiation. Whatever is seen first by the compiler then it's inserted to the type table and that is the type used by any function templates. Second, there's a special code path in the presence of default arguments that just passes the original argument to the template, here is 'func' with the @system flag enabled, not the one in the type table (alias T = void delegate()), this peculiarity is orthogonal to the main issue. Possible solutions are: 1. Integrate @system attribute in the mangle system. 2. That .stringof just print the naked functions (no attributes) with @system. 3. or better, save the type of these functions in the type table with the @system flag enabled (or @safe in the hypothetical case of safe by default). 2 and 3 mean the compiler should now interpret ("no attributes" == @system) -- |
August 14, 2020 [Issue 18269] Inconsistent string representation of delegate @system attribute | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=18269 --- Comment #8 from hsteoh@quickfur.ath.cx --- Solution 3 sounds like the best solution. -- |
December 17, 2022 [Issue 18269] Inconsistent string representation of delegate @system attribute | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=18269 Iain Buclaw <ibuclaw@gdcproject.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P1 |P3 -- |
Copyright © 1999-2021 by the D Language Foundation