X10

X10DT: Red marks in edit buffer, even though there are no errors

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: X10DT 1.7
  • Fix Version/s: X10 2.0.3
  • Component/s: X10DT Source Editor
  • Labels:
    None
  • Number of attachments :
    2

Description

Attached source program.

X10DT displays red marks in the edit buffer. However, there are no compilation errors. No errors show up in Problems view, there are no red marks against the class name in the PackageExplorer view and the FileName in the editor tab is not marked with a red cross.

Looks like some display data-structure is not refreshed.

This happened at the end of a complicated edit cycle on X10 code, during which several errors were removed.

  1. File
    TestTypeDef.x10
    25/May/09 9:00 AM
    1 kB
    Vijay Saraswat
  1. RedMarks.jpg
    177 kB
    25/May/09 9:00 AM

Issue Links

is duplicated by

Bug - A problem which impairs or prevents the functions of the product. XTENLANG-1209 X10DT editor: Wrong icon displayed for a file with a compilation error

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
David Grove added a comment -

Moving all open items for X10DT 1.7 to X10DT 2.0 since 1.7 has been released.

Show
David Grove added a comment - Moving all open items for X10DT 1.7 to X10DT 2.0 since 1.7 has been released.
Hide
Permalink
Robert M. Fuhrer added a comment -

Need to determine whether this is still a problem for 2.0.1; luckily we have the source, Luke.

Show
Robert M. Fuhrer added a comment - Need to determine whether this is still a problem for 2.0.1; luckily we have the source, Luke.
Hide
Permalink
David Grove added a comment -

Defer all unresolved issues from 2.0.2 to 2.0.3.

Show
David Grove added a comment - Defer all unresolved issues from 2.0.2 to 2.0.3.
Hide
Permalink
Robert M. Fuhrer added a comment -

At the moment, I can't recreate this problem, partly since the attached source doesn't compile under 2.0.

Even though the original error probably had little to do with the source, I haven't seen this with any other source lately, so I guess I'll have to migrate the source to 2.0 first before I can make a diagnosis.

Show
Robert M. Fuhrer added a comment - At the moment, I can't recreate this problem, partly since the attached source doesn't compile under 2.0. Even though the original error probably had little to do with the source, I haven't seen this with any other source lately, so I guess I'll have to migrate the source to 2.0 first before I can make a diagnosis.
Hide
Permalink
Robert M. Fuhrer added a comment -

This problem was due to the fact that the editor wasn't tracking changes to marker state, when the marker state changed as a result of changes to other source files. Thus the source editor annotations from a previous compiler run were left in place, even though the underlying problem was resolved, and the corresponding problem marker was removed.

This has been worked around (slightly inefficiently) by re-scheduling a parse when the problem marker state changes on a file open in an editor buffer.

A more efficient solution (that of matching a new set of problem markers against the existing set of problem annotations in the source editor) would require that the compiler messages be completely identical across runs. E.g. the current use of "instantiations" of existentially-quantified variables, like "self35135" and "place25188" in messages needs to be changed, so that messages identifying a given type are completely identical from one compiler run to the next.

Show
Robert M. Fuhrer added a comment - This problem was due to the fact that the editor wasn't tracking changes to marker state, when the marker state changed as a result of changes to other source files. Thus the source editor annotations from a previous compiler run were left in place, even though the underlying problem was resolved, and the corresponding problem marker was removed. This has been worked around (slightly inefficiently) by re-scheduling a parse when the problem marker state changes on a file open in an editor buffer. A more efficient solution (that of matching a new set of problem markers against the existing set of problem annotations in the source editor) would require that the compiler messages be completely identical across runs. E.g. the current use of "instantiations" of existentially-quantified variables, like "self35135" and "place25188" in messages needs to be changed, so that messages identifying a given type are completely identical from one compiler run to the next.
Hide
Permalink
David Grove added a comment -

bulk close of all resolved issues as part of closing 2.0.4 items.

Show
David Grove added a comment - bulk close of all resolved issues as part of closing 2.0.4 items.

People

  • Assignee:
    Robert M. Fuhrer
    Reporter:
    Vijay Saraswat
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: