[Issue 4595] [tdpl] Accessing non-static member of a null reference compiles

[d-bugmail--- via Digitalmars-d-bugs]

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

RazvanN  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |WONTFIX

--- Comment #18 from RazvanN  ---
I'm going to close this since Walter is against dataflow analysis in this sort
of situations.

--

[Issue 4595] [tdpl] Accessing non-static member of a null reference compiles

[via Digitalmars-d-bugs]

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

Andrej Mitrovic  changed:

   What|Removed |Added

 OS|Windows |All

--- Comment #17 from Andrej Mitrovic  ---
Well, six years after filing this I'm having second thoughts.

Is anyone aware of competing language compilers which do this type of analysis
at compile-time?

I'm aware of static analysis tools (like pvs-studio), which make me think we
should have something like that for D. A tool, rather than something built-in
to the compiler. I can imagine having this in the compiler would be complicated
to implement and have a lot of missed cases, or worse, false-positives.

--

[Issue 4595] [tdpl] Accessing non-static member of a null reference compiles

[d-bugmail]

https://d.puremagic.com/issues/show_bug.cgi?id=4595


Andrej Mitrovic andrej.mitrov...@gmail.com changed:

   What|Removed |Added

 CC||sumit.adhik...@gmail.com


--- Comment #16 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-01-23 
08:13:19 PST ---
*** Issue 11975 has been marked as a duplicate of this issue. ***

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4595] [tdpl] Accessing non-static member of a null reference compiles

[d-bugmail]

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



--- Comment #14 from Kenji Hara k.hara...@gmail.com 2013-09-19 00:33:55 PDT 
---
(In reply to comment #13)
 After a few years of D use, I actually find the above will create problems. We
 often use traits like these to check whether something is compilable, even if
 the object is left uninitialized. 

Today, code flow analysis for class ctor call (super(...) and this(...))
behaves as follows.

class Foo
{
this(int) {}
}

class Bar : Foo
{
this()
{
static assert(is(typeof(super(0;
static if (is(typeof(super(0 {}
// inside typeof(), code flow analysis never works.

super(1);
// OK

static assert(is(typeof(super(0;
static if (is(typeof(super(0 {}
// also OK

super(2);
// Error: multiple constructor call
}
this(int)
{
static assert( __traits(compiles, super(1)));
// inside __traits(compiles), code flow analysis is enabled.

super(1);
// Error: multiple constructor call

static assert(!__traits(compiles, super(2)));
// The _second_ super call makes error.

super(3);
// Error: multiple constructor call
}
}

This is expected behavior, from my compiler-internal knowledge.

- `is(typeof(exp))` tests that the exp has valid type or not. For type
calculation, the code flow analysis and its validation result is just
unnecessary.

- `__traits(compiles, exp)` tests the exact validness of `exp` at there. In
other words, `__traits(compiles)` converts the error occurrence on the `exp`
semantic analysis to the compile-time boolean value. In there, code flow
analysis is enabled, and the errors will be counted normally.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4595] [tdpl] Accessing non-static member of a null reference compiles

[d-bugmail]

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



--- Comment #15 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-09-19 
03:52:35 PDT ---
(In reply to comment #14)
 - `is(typeof(exp))` tests that the exp has valid type or not. For type
 calculation, the code flow analysis and its validation result is just
 unnecessary.
 
 - `__traits(compiles, exp)` tests the exact validness of `exp` at there. In
 other words, `__traits(compiles)` converts the error occurrence on the `exp`
 semantic analysis to the compile-time boolean value. In there, code flow
 analysis is enabled, and the errors will be counted normally.

Well that explains why sometimes is(typeof()) works where __traits(compiles)
doesn't.

But as far as I know none of this is properly documented, and it's probably why
people file bugs when a difference in behavior is found.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4595] [tdpl] Accessing non-static member of a null reference compiles

[d-bugmail]

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



--- Comment #13 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-09-17 
12:54:33 PDT ---
(In reply to comment #12)
 Failing unittest in TDPL:
 
 unittest
 {
   class A { int x; }
   A a;
   assert(!__traits(compiles, a.x = 5));
 }
 
 Such programs must be statically rejected, guaranteed if there's no 
 intervening
 flow in between definition and first use. We can work on improving that later,
 but for now let's get the obvious case out of the way.

After a few years of D use, I actually find the above will create problems. We
often use traits like these to check whether something is compilable, even if
the object is left uninitialized. 

For example if you want to check whether method foo of object c is callable
with an int type:

static assert(__traits(compiles, c.foo(1)));

Making this fail now because of flow analysis could hurt code that does
unittesting.

I think a runtime exception is sufficient right now, and the OP feature could
be part of some specialized flow-analysis tool.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---

[Issue 4595] [tdpl] Accessing non-static member of a null reference compiles

[d-bugmail]

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


Andrei Alexandrescu and...@metalanguage.com changed:

   What|Removed |Added

 CC||and...@metalanguage.com
Summary|Accessing non-static member |[tdpl] Accessing non-static
   |of a null reference |member of a null reference
   |compiles|compiles


--- Comment #12 from Andrei Alexandrescu and...@metalanguage.com 2011-12-18 
20:20:09 PST ---
Failing unittest in TDPL:

unittest
{
  class A { int x; }
  A a;
  assert(!__traits(compiles, a.x = 5));
}

Such programs must be statically rejected, guaranteed if there's no intervening
flow in between definition and first use. We can work on improving that later,
but for now let's get the obvious case out of the way.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---