[REG2.063a] Issue 10096 - __traits(allMembers) triggers out of bounds error

[9rnsr]

http://d.puremagic.com/issues/show_bug.cgi?id=10096

Do not list internal members in __traits(allMembers)

• Names starting double underscore does not appear its result.
  Now, __cpctor, __invariant, __xopEquals, __fieldPostBlit, __aggrPostBlit, __fieldDtor, __aggrDtor, and others are not listed in there.
• Except __ctor, __dtor, and __postblit. They are already used in Phobos, so temporary keep them for backward compatibility.

[IgorStepanov]

"By the way question". For nested classes __traits(allMember) doesn't show "outer" pseudo-field. Why? Yes, this field automatically adding by compiler. but this is real field with offset value, for example. May be we need to add this field to __traits(allMember) result for nested classes?

[IgorStepanov]

About "__ctor": Do this name is documented and considered standart? I'm working under runtime reflections extension for druntime now, and I must know: Can I use __traits(allMember) for __ctor finding or I need to add special-case for this function. Can I use this name (__ctor) to constructor finding?

[9rnsr]

Because dmd does not map outer directly to the hidden context field. It would behave as same as built-in stringof property.

[9rnsr]

I think __(ctor|dtor|__postblit) should not be documented. For the problem, I opened bug 10097.

[IgorStepanov]

I think __(ctor|dtor|__postblit) should not be documented. For the problem, I opened bug 10097.

Is there another way to access to constructor/destrucor functions? And not simple access, but finding all overloads with __traits(getOverloads, Foo, "XXX"). Mat be we can use this keyword for it?

struct Foo
{
  this(int){}
  this(this){}
  ~this(){}
}

We can allow next syntax:
Foo.this -- simple constructor and may be postblit.
Foo.~this -- destructor.
__traits(getOverloads, Foo, "this"); //All constructors include postblit.

Because dmd does not map outer directly to the hidden context field. It would behave as same as built-in stringof property.

outer field looks like field. We can get offset of it, pass by ref to function and get pointer of it.

class Bar
{
    class Nested
    {

    }
}

ref Bar byRef(ref Bar b)
{
    return b;
}

void main()
{
    auto nested = (new Bar).new Bar.Nested;
    enum off = nested.outer.offsetof;//we can get offset
    void* pnested = &nested.outer;   //get pointre
    auto b = byRef(nested.outer);    //and path by ref
}

[ghost]

LGTM.

[ghost]

Can't we disable this test at least for freebsd:

core.thread.ThreadException@src/core/thread.d(886): Unable to set thread priority

It's really wasting so much time for us..

[braddr]

It happens most often on freebsd, true, but it does happen on other
platforms as well. The "wasting time" phrase is a bad one too. It's
exposing a very real problem which is pretty much the entire point of
doing the testing.

I'm rather against disabling it. If it bothers you, and it should, then
the right answer is to volunteer to investigate and fix. It's certainly
unlikely to fix itself.

On 5/16/13 1:14 PM, Andrej Mitrovic wrote:

Can't we disable this test at least for freebsd:

|core.thread.ThreadException@src/core/thread.d(886): Unable to set thread priority
|

It's really wasting so much time for us..

—
Reply to this email directly or view it on GitHub
#2043 (comment).

[ghost]

Someone who knows their way around Posix and concurrency (ideally the implementer) should work on it. I know very little about the two or I'd jump in with both hands.

[IgorStepanov]

What is a cause of this fall? What code pthread_getschedparam return before test fall?

[dnadlinger]

Interestingly, the thread priority issue has also started to occur on my Linux box recently, when I was running some rather unrelated test case in the bugger. Haven't had time to investigate it more closely, though – it still seems to occur highly non-deterministically.

[IgorStepanov]

May be we need to add more debug print in error point? I think, we need to know returned value of pthread_getschedparam and m_addr. As I know, pthread_getschedparam has a single error case: invalid thread address. Can m_addr be invalid?

[ibuclaw]

This caused a regression.

https://issues.dlang.org/show_bug.cgi?id=10100