[Issue 20982] Add a pragma to suppress deprecation messages
https://issues.dlang.org/show_bug.cgi?id=20982
--- Comment #2 from Andrei Alexandrescu ---
Another idea from Stefan was to control this programmaticaly:
static if (deprecated(symbol)) {
... avoid ...
}
--
[Issue 20982] Add a pragma to suppress deprecation messages
https://issues.dlang.org/show_bug.cgi?id=20982 Stefan Koch changed: What|Removed |Added CC||uplink.co...@gmail.com --- Comment #1 from Stefan Koch --- perhaps it should be pargma(push, deprecated, false) then. together with pragma(pop, deprecated)? --
[Issue 20982] Add a pragma to suppress deprecation messages
https://issues.dlang.org/show_bug.cgi?id=20982 Andrei Alexandrescu changed: What|Removed |Added Keywords||industry --
[Issue 20982] New: Add a pragma to suppress deprecation messages
https://issues.dlang.org/show_bug.cgi?id=20982 Issue ID: 20982 Summary: Add a pragma to suppress deprecation messages Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: and...@erdani.com In introspection code, often just enumerating the members of a type with deprecated members will issue deprecated warnings. We'd need a pragma(deprecated, false) directive to temporarily disable deprecation messages. Then pragma(deprecated, restore) to restore to its set value. --
[Issue 20981] Segfault for inlined __simd_sto
https://issues.dlang.org/show_bug.cgi?id=20981 moonlightsenti...@disroot.org changed: What|Removed |Added Severity|enhancement |regression --
[Issue 20981] New: Segfault for inlined __simd_sto
https://issues.dlang.org/show_bug.cgi?id=20981
Issue ID: 20981
Summary: Segfault for inlined __simd_sto
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Severity: enhancement
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: moonlightsenti...@disroot.org
The following code segfaults on linux64 when compiled with -O -inline:
import core.simd; // Import need for intrinsics
void main()
{
void16 a;
simd_sto!(XMM.STOUPS)(a, a);
}
void16 simd_sto(XMM opcode)(void16 op1, void16 op2)
{
return cast(void16) __simd_sto(opcode, op1, op2);
}
--
[Issue 20981] Segfault for inlined __simd_sto
https://issues.dlang.org/show_bug.cgi?id=20981 --- Comment #1 from moonlightsenti...@disroot.org --- Digger blames this PR: https://github.com/dlang/dmd/pull/6815 --
[Issue 20980] std.bigint.BigInt: special case x & 1 to avoid unnecessary allocation
https://issues.dlang.org/show_bug.cgi?id=20980 Dlang Bot changed: What|Removed |Added Keywords||pull --- Comment #1 from Dlang Bot --- @n8sh created dlang/phobos pull request #7544 "std.bigint.BigInt: special case x & 1 to avoid unnecessary allocation" fixing this issue: - Fix Issue 20980 - std.bigint.BigInt: special case x & 1 to avoid unnecessary allocation https://github.com/dlang/phobos/pull/7544 --
[Issue 20980] New: std.bigint.BigInt: special case x & 1 to avoid unnecessary allocation
https://issues.dlang.org/show_bug.cgi?id=20980 Issue ID: 20980 Summary: std.bigint.BigInt: special case x & 1 to avoid unnecessary allocation Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: phobos Assignee: nob...@puremagic.com Reporter: n8sh.second...@hotmail.com `x & 1` is a natural way to check the low bit of `std.bigint.BigInt x` but that allocates unlike the less natural `x.getDigit!uint(0) & 1`. Examples in Phobos of code that does this are `std.bigint.powmod(BigInt, BigInt, BigInt)` (a PR to fix it is pending) and `std.numeric.gcd!T(T, T)` when instantiated for `BigInt`. Adding special handling for `x & 1` will aside from helping naive uses also improve performance of generic templated code that operates on arbitrary number-like types. --
[Issue 20023] Separate compilation breaks dip1000 / dip1008 @safety
https://issues.dlang.org/show_bug.cgi?id=20023 --- Comment #4 from John Colvin --- Discussed on a call with Walter, seems like he misunderstood the original example. To be clear: putting -dip1000 -dip1008 -dip25 on all the modules does not mean all the code is actually checked by those dips. --
[Issue 9816] Export is mostly broken
https://issues.dlang.org/show_bug.cgi?id=9816 Mike Parker changed: What|Removed |Added CC||aldac...@gmail.com --- Comment #32 from Mike Parker --- A bounty has been placed on this issue: https://www.flipcause.com/secure/cause_pdetails/ODcyMDE= --
[Issue 19399] Different Conversion Rules for Same Value and Type -- Enum
https://issues.dlang.org/show_bug.cgi?id=19399
--- Comment #12 from Simen Kjaeraas ---
(In reply to Walter Bright from comment #10)
> (In reply to Simen Kjaeraas from comment #5)
> > However, when the type is explicitly specified, the error occurs:
> >
> > enum P : ulong {
> > P = 10
> > }
> > // Should call the ulong overload, but type information is discarded and the
> > ubyte overload is called instead. This assert will fail.
> > static assert(fun(P.P) == 1);
>
> ulong is NOT the type. The type is an enum that is implicitly convertible to
> its base type, which is ulong.
>
> The match to both functions is by conversion, which is resolved by partial
> ordering, again picking fun(ubyte).
Agreed on all points. The problem may instead be said to be with intuition - it
seems natural that two conversions are involved when converting P.P to an int:
first the enum is converted to its base type, then that is converted to int.
Furthermore, two conversions seems like a worse match than a single conversion.
I acknowledge that's not how it works or is specified to work, but I can see
expectations being different.
--
[Issue 19044] Linking error: reloc 0: symbol index out of range
https://issues.dlang.org/show_bug.cgi?id=19044 Mike Parker changed: What|Removed |Added CC||aldac...@gmail.com --- Comment #2 from Mike Parker --- A bounty has been placed on this issue: https://www.flipcause.com/secure/cause_pdetails/ODgxMDc= --
[Issue 4071] Missing support to share memory and objects between DLLs and executable
https://issues.dlang.org/show_bug.cgi?id=4071 Mike Parker changed: What|Removed |Added CC||aldac...@gmail.com --- Comment #12 from Mike Parker --- A bounty has been placed on this issue: https://www.flipcause.com/secure/cause_pdetails/ODcyMDE= --
[Issue 19399] Different Conversion Rules for Same Value and Type -- Enum
https://issues.dlang.org/show_bug.cgi?id=19399 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --
[Issue 19399] Different Conversion Rules for Same Value and Type -- Enum
https://issues.dlang.org/show_bug.cgi?id=19399 --- Comment #11 from Walter Bright --- (In reply to David Eckardt from comment #6) > I see two more issues here. Please file them as two separate issues, as they are not applicable here. --
[Issue 10560] Enum typed as int with value equal to 0 or 1 prefer bool over int overload
https://issues.dlang.org/show_bug.cgi?id=10560 Walter Bright changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |INVALID --- Comment #7 from Walter Bright --- See detailed explanation in https://issues.dlang.org/show_bug.cgi?id=19399 This is not a bug, it is a misunderstanding of how match levels and partial ordering works. --
[Issue 19399] Different Conversion Rules for Same Value and Type -- Enum
https://issues.dlang.org/show_bug.cgi?id=19399
--- Comment #10 from Walter Bright ---
(In reply to Simen Kjaeraas from comment #5)
> I started out thinking this was not a bug, since enum values are basically
> inserted verbatim into the code. And indeed, this is exactly what should
> happen in cases like this:
>
> int fun(ubyte) { return 0; }
> int fun(ulong) { return 1; }
>
> enum M = 10;
> // Exactly equivalent to foo(10); - will call the ubyte overload.
> static assert(fun(M) == 0);
Correct, because M is typed as an int and matches with conversion to both
fun(ubyte) and fun(ulong), then partial ordering picks fun(ubyte).
> However, this intuition breaks down when the enum has a specified type:
>
> enum ulong N = 10;
> // Will always call the ulong overload.
> static assert(fun(N) == 1);
Correct, because here N is typed as a ulong, and so will pick fun(ulong) which
is an exact match, while fun(ubyte) is a match with conversion.
> Both of these cases are working correctly. The error is with enums with
> curly brackets. If no type is specified for the enum, the behavior is
> correct:
>
> enum O {
> O = 10
> }
> // Exactly equivalent to foo(10); - will call the ubyte overload.
> static assert(fun(O.O) == 0);
Yes, because O is an enum that converts to both ubyte and ulong, then partial
ordering picks f(ubyte).
> However, when the type is explicitly specified, the error occurs:
>
> enum P : ulong {
> P = 10
> }
> // Should call the ulong overload, but type information is discarded and the
> ubyte overload is called instead. This assert will fail.
> static assert(fun(P.P) == 1);
ulong is NOT the type. The type is an enum that is implicitly convertible to
its base type, which is ulong.
The match to both functions is by conversion, which is resolved by partial
ordering, again picking fun(ubyte).
> VRP, as pointed out by Simon in comment 1, is what causes the conversions,
> even in the array examples in comment 4. Simply put, the compiler prefers to
> interpret a number as an int, but will try other types if they are a better
> fit. The only issue is that VRP is used when a type is explicitly specified
> for an enum with braces.
No, this is not what is happening here.
The compiler is working correctly as specified by the language.
--
[Issue 19399] Different Conversion Rules for Same Value and Type -- Enum
https://issues.dlang.org/show_bug.cgi?id=19399
--- Comment #9 from Walter Bright ---
(In reply to Sprink from comment #0)
> void foo(byte v) { writeln("byte ", v); }
> void foo(int v) { writeln("int ", v); }
>
> enum A : int {
> a = 127,
> b = 128, // shh just ignore this
> }
>
> void main()
> {
> A v = A.a;
> foo(A.a); // byte 127
> foo(v);// int 127 should be byte 127
> }
foo(A.a) is passing an integer literal of type enum and value 127. 127 can be
implicitly converted to both byte and int, so foo(byte) and foo(int) both match
with conversion level 2. Partial ordering selects foo(byte).
foo(v) is passing an integer variable of type enum with a base type of int.
This cannot be implicitly converted to byte, but it can be implicitly converted
to int. Hence, foo(int) is selected. Partial ordering does not come into play.
Note that the compiler explicitly does NOT do data flow analysis in the front
end to determine that v is 127.
The compiler is working correctly as the language is designed.
--
[Issue 19399] Different Conversion Rules for Same Value and Type -- Enum
https://issues.dlang.org/show_bug.cgi?id=19399
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #8 from Walter Bright ---
Here's how function overload resolution works:
f(ubyte);
f(ushort);
enum E : ushort { a = 10; }
f(E.a); // which is called?
There are 4 matching levels, 1 is worst and 4 is best:
1. no match
2. implicit conversion
3. conversion to const
4. exact match
E.a can be implicitly converted to a ubyte.
E.a can also be implicitly converted to ushort.
Both are match level 2. To disambiguate this, we now move to "partial
ordering". For partial ordering, we ignore what the argument is. We only look
at the function parameters. We ask the question "can the parameters of f(ubyte)
be used to call the f(ushort)?" The answer is yes, because ubyte can be
implicitly converted to ushort. Then we ask "can the parameters of f(ushort) be
used to call f(ubyte)?" The answer is no, because ushort cannot be implicitly
converted to ubyte.
Therefore, f(ubyte) is "more specialized", and the more specialized function is
selected.
Partial matching is a powerful method, and is far simpler than the C++ method
of having a couple pages of match levels which nobody understands. Tellingly,
C++ switch from match levels to partial ordering for template overload
resolution.
D benefited by this experience and uses partial ordering for both functions and
templates.
The compiler is correctly implementing the language semantics.
--
