-
-
Notifications
You must be signed in to change notification settings - Fork 637
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revise ABI-specific part of -preview=in #11828
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -13,11 +13,10 @@ void testWithAllAttributes() @safe pure nothrow @nogc | |
|
||
// rvalues | ||
testin1(42); | ||
testin2([42, ulong.max, ulong.min, 42UL]); | ||
testin2((ulong[64]).init); | ||
testin3(ValueT(42)); | ||
testin3(RefT(42)); | ||
testin4([ValueT(0), ValueT(1), ValueT(2), ValueT(3), | ||
ValueT(4), ValueT(5), ValueT(6), ValueT(7)]); | ||
testin4((ValueT[64]).init); | ||
testin4([RefT(42), RefT(84), RefT(126), RefT(4)]); | ||
testin5(NonCopyable(true)); | ||
testin6(WithPostblit(true)); | ||
|
@@ -27,14 +26,14 @@ void testWithAllAttributes() @safe pure nothrow @nogc | |
isTestOver = false; | ||
|
||
// lvalues | ||
uint a1; | ||
ulong[4] a2; | ||
ValueT a3; | ||
ValueT[8] a4; | ||
RefT a5; | ||
RefT[4] a6; | ||
uint a1; | ||
ulong[64] a2; | ||
ValueT a3; | ||
ValueT[64] a4; | ||
RefT a5; | ||
RefT[4] a6; | ||
NonCopyable a7 = NonCopyable(true); | ||
WithPostblit a8; | ||
WithPostblit a8; | ||
WithCopyCtor a9; | ||
WithDtor a10 = WithDtor(&isTestOver); | ||
|
||
|
@@ -118,7 +117,7 @@ void testForeach() @safe pure | |
} | ||
|
||
struct ValueT { int value; } | ||
struct RefT { ubyte[64] value; } | ||
struct RefT { ulong[64] value; } | ||
|
||
struct NonCopyable | ||
{ | ||
|
@@ -155,25 +154,27 @@ struct WithDtor | |
@safe pure nothrow @nogc: | ||
|
||
// By value | ||
void testin1(in uint p) {} | ||
void testin1(in uint p) { static assert(!__traits(isRef, p)); } | ||
// By ref because of size | ||
void testin2(in ulong[4] p) {} | ||
void testin2(in ulong[64] p) { static assert(__traits(isRef, p)); } | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Increasing the size just to be on the safe side - some ABIs might be able to pass a 32-bytes aggregate in registers. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Doesn't seem wise to add a static assert here. You're forcing a behaviour when there is no spec on one. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's not spec'd, but if a 512-bytes arg is ever to be copied, then Edit: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you mean, passed in memory? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I mean passed by-value, i.e., the thing that is tested that it's not. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, isRef would mean that no copy is made? There would still need to be spec on that though. From my reading of it, only non-trivial types must be passed by ref. Everything else either explicitly by value, or unenforceable. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's not spec'd, but do you see any ABI on the horizon where it would be advantageous to pass half a KB by value over passing a ref? If that's the case in a few decades, the test can be adapted, until then, it makes sure the implementation is up to the expectation of eliding expensive copies. |
||
// By value or ref depending on size | ||
void testin3(in ValueT p) {} | ||
void testin3(in RefT p) {} | ||
void testin3(in ValueT p) { static assert(!__traits(isRef, p)); } | ||
void testin3(in RefT p) { static assert(__traits(isRef, p)); } | ||
// By ref because of size | ||
void testin4(in ValueT[8] p) {} | ||
void testin4(in RefT[4] p) {} | ||
void testin4(in ValueT[64] p) { static assert(__traits(isRef, p)); } | ||
void testin4(in RefT[4] p) { static assert(__traits(isRef, p)); } | ||
|
||
// By ref because of non-copyability | ||
void testin5(in NonCopyable noncopy) {} | ||
void testin5(in NonCopyable noncopy) { static assert(__traits(isRef, noncopy)); } | ||
static assert(testin5.mangleof == "_D9previewin7testin5FNaNbNiNfIKSQBe11NonCopyableZv"); // incl. `ref` | ||
// By ref because of postblit | ||
void testin6(in WithPostblit withposblit) {} | ||
void testin6(in WithPostblit withpostblit) { static assert(__traits(isRef, withpostblit)); } | ||
// By ref because of copy ctor | ||
void testin7(in WithCopyCtor withcopy) {} | ||
void testin7(in WithCopyCtor withcopy) { static assert(__traits(isRef, withcopy)); } | ||
// By ref because of dtor | ||
void testin8(in WithDtor withdtor, scope bool* isTestOver) | ||
{ | ||
static assert(__traits(isRef, withdtor)); | ||
if (isTestOver) | ||
*isTestOver = true; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wish I'd knew we'd go this way earlier :)
Personally I don't mind, but it goes against @tsbockman 's review and what was discussed in the forum thread.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, I've always mentioned that it should be based on the param type only. And the implementation proposals here and for LDC make no use the of param position, and I doubt Iain will make use of it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only part that might be interesting is the relationship of the
in
parameter with other parameters, but that's something which is diagnosed much later, and not determinable from inspecting the function signature alone.