[Octave-bug-tracker] [bug #46536] Bad indexing could produce more informative error messages

[Lachlan Andrew]

Follow-up Comment #11, bug #46536 (project octave):

Thanks for your feedback Rik (and jwe) -- it is making the patch much better,
and I'm learning lots.

Version 5 of the patch:
- indicates which position is in error in an r-value, provided the only thing
following a "(" is a ".", as required by Matlab.
- indicates the structure components leading up to a single "(" in an
assignment statement.
- writes c...(-1)  instead of c<...>(-1) in other cases, in an attempt to put
less "visual distance" between the "c" and the "(-1)", so that  c(-1).foo(1) 
seems a more plausible bug to look for.

There is more code in the error path, but no additional code on the fast path,
except fixing what I think is a bug, as follows.

I think the definition of force_split was wrong.  It was


// In Matlab, () can only be followed by . In Octave, we do not
// enforce this for rvalue expressions, but we'll split the
// evaluation at this point. This will, hopefully, allow Octave's
// looser rules apply smoothly for Matlab overloaded subsref
// codes.
bool force_split = type[i-1] == '(' && type[i] != '.';


which forces a split whenever () is *not* followed by ., whereas the comment
says that the split is forced whenever () *is* followed by '.'.  The splits
are useful to determine which () has the error.  The patch currently replaces
!= by ==.  Is that what was actually intended?

(file #35777)
    _______________________________________________________

Additional Item Attachment:

File name: bug_46536.v5.cset              Size:13 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?46536>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/