bugGNU Octave - Bugs: bug #57239, errors in multiline constructs...

 
 

bug #57239: errors in multiline constructs show incorrect line numbers

Submitter:  Lars Kindermann <larskindermann>
Submitted:  Thu 14 Nov 2019 11:31:29 PM UTC
   
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 13 Jan 2022 10:05:15 AM UTC, comment #9: 

Thanks for testing.
Closing as fixed as per comment #8.

Markus Mützel <mmuetzel>
Group administrator
Thu 13 Jan 2022 07:17:54 AM UTC, comment #8: 

Checked in 7.0.91 - the bug is fixed there, so this can be closed.

Lars Kindermann <larskindermann>
Fri 06 Dec 2019 06:41:33 PM UTC, comment #7: 

Rik: I think I was confusing this bug report with bug #57159.  The patch I pushed should help with accuracy of token locations, but may not do much for the locations of expressions and statements.  I'll work on storing more information for those parse tree objects next.

John W. Eaton <jwe>
Group administrator
Fri 06 Dec 2019 04:30:39 PM UTC, comment #6: 

At least for the example in this bug report, there is no change.  The error is still reported as being at the final line of the sequence.

Rik <rik5>
Group administrator
Fri 06 Dec 2019 07:45:58 AM UTC, comment #5: 

I pushed a few changesets aimed at storing beginning and ending locations for all tokens recognized by the lexer.  I hope it improves the accuracy of the line and column info displayed in error messages but I wouldn't be at all surprised if I missed some things.  If you notice incorrect location info in an error message after my recent changes, then please submit bug reports and I'll try to fix.

John W. Eaton <jwe>
Group administrator
Mon 02 Dec 2019 08:16:35 PM UTC, comment #4: 

I don't think it's too hard to do.  We probably need to store more info for each parse tree element.  Currently we store a single line and column pair.  We may need to store the beginning and ending location and we need to attach that to each token and tree object.  Then I think we should be able to display the correct line and column info for any error.

I've also noticed some incorrect column info, either off by one errors or problems with incrementing and storing in the wrong order.

John W. Eaton <jwe>
Group administrator
Mon 02 Dec 2019 06:38:05 PM UTC, comment #3: 

Adding jwe to the CC list as he has recently resolved two bug reports dealing with the parser and line counting.

We could also throw this question to the Octave Maintainer's list.  If this is too hard to handle correctly then I think Octave just shouldn't report the line numbers at all.

Rik <rik5>
Group administrator
Fri 15 Nov 2019 08:45:09 AM UTC, comment #2: 

see also bug #57205 for some discussion about error messages like this

Lars Kindermann <larskindermann>
Fri 15 Nov 2019 12:30:16 AM UTC, comment #1: 

and column is always the same as line...

Lars Kindermann <larskindermann>
Thu 14 Nov 2019 11:31:29 PM UTC, original submission:  

enter this into the command window:


if 1
2
asdf
4
5
end


result:


ans = 2
error: 'asdf' undefined near line 5, column 5
>>


But the error is in line 3, not 5.

Lars Kindermann <larskindermann>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by larskindermann (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-01-13 mmuetzel StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2019-12-06 rik5 StatusNone Confirmed
    2019-12-02 rik5 Carbon-Copy- Added jwe

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code