[ nice-Feature Requests-681385 ] nullness analysis in presence of assignments

Feature Requests item #681385, was opened at 2003-02-06 04:02
Message generated for change (Comment added) made by artemgr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362788&aid=681385&group_id=12788

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Arjan Boeijink (arjanb)
Assigned to: Nobody/Anonymous (nobody)
Summary: nullness analysis in presence of assignments

Initial Comment:
Nice compiler version 0.7.7 (build 2003.01.28, 19:00:34 
UTC)
example1:
void foo(){
  ?String s = "";
  while(s.endsWith("xyz")){}
}
example2:
void foo(){
  ?String s = "";
  while(false){print(s.endsWith("xyz"));}
}
both yield the following error message:
Arguments (?java.lang.String, java.lang.String) do not fit:
nice.lang.boolean endsWith(java.lang.String, 
java.lang.String)
It looks like the compiler doesn't pass the info it has 
about the nullness to loops.
If it's not a bug then it's a feature request.


----------------------------------------------------------------------

Comment By: Artem Gr Kozarezov (artemgr)
Date: 2005-03-07 13:38

Message:
Logged In: YES 
user_id=289741

Excerpt from the NEWS:

  * Nullness analysis of assignments (RFE 681385) is
partially implemented.
    It is now possible to write:
      class Foo {}
      var ?Foo FOO_INSTANCE = null;
      Foo getFooInstance(){
        var instance = FOO_INSTANCE; if( null != instance )
return instance;
        instance = new Foo(); FOO_INSTANCE = instance;
return instance;
      }
    becouse Nice will detect that "instance" is of a "sure type"
    after the "instance = new Foo();" assignment.


----------------------------------------------------------------------

Comment By: Luc Perrin (leblin)
Date: 2003-03-13 08:16

Message:
Logged In: YES 
user_id=717201

I think nullness analysis on assignments is more important 
that what is demonstrated in this example.  Consider the 
following example:

Foo func( ?Foo foo ) {
  if( foo == null ) {
     foo = new Foo( );
  }
  // Do some operations
 return foo;
}

The constructor does not return an option type, so foo is 
non null for the remainder of the first if() clause.  Since the 
non-existant else clause also guarantees a non null Foo, 
then foo is surely non null for the code following the if() 
statement.


----------------------------------------------------------------------

Comment By: Arjan Boeijink (arjanb)
Date: 2003-02-17 20:23

Message:
Logged In: YES 
user_id=688815

I think cases like the first will not happen often in code that 
isn't for testing purposes. I will put it on my todo with a low 
priority.

----------------------------------------------------------------------

Comment By: Daniel Bonniot (bonniot)
Date: 2003-02-17 20:07

Message:
Logged In: YES 
user_id=88952

OK, I commited today your patch, which solves the *second* case.
For the initial problem, I don't consider it a bug, but it
could be a new feature.
Do you plan to work on it?


----------------------------------------------------------------------

Comment By: Arjan Boeijink (arjanb)
Date: 2003-02-08 15:01

Message:
Logged In: YES 
user_id=688815

I think I was looking for a bug in the wrong direction.
But the problem is the following code:

?String line;
while( (line = reader.readLine()) != null) {
  line.trim();
  ...
}


----------------------------------------------------------------------

Comment By: Daniel Bonniot (bonniot)
Date: 2003-02-08 05:09

Message:
Logged In: YES 
user_id=88952

I don't think this is related to loops. You would get the
same with:

?String s = "";
print(s.endsWith("xyz"));

Nullness analysis does not take into account the values
stored in a variable, but only its declared type, and the
tests to null, like: if (s != null) ... (following which
branches can complete normally).

In most cases, if you assign a non-null value, you could
also declare the type of the variable as non-null. Now it is
true that in some cases you cannot, like if the value is not
null in only one branch of a conditinal. Now you would need
to also store the value in another variable, to show the
compiler that that one is not-null. Do you have a real-life
example where this is needed?

So I agree the analysis could be finer. I'm not sure if it
could be added easily to the current mechanism. If you are
interested you can look at bossa/syntax/typecheck.nice, it
is all there. But be careful, it could be easy to introduce
a bug that makes a non-nullness information leak outside of
its scope, creating a type safety hole.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362788&aid=681385&group_id=12788


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click