internal: consider column for TLineInfo equality

[bung87]

Summary

Change the default equality operation for TLineInfo to also consider
the column, effectively changing the meaning of TLineInfo to "source
position info". Places in the compiler that relied on the old behaviour
are adjusted.

In most cases, a TLineInfo is already treated as a "source position",
so having the == operator reflect that makes sense. The hash
procedure also already considered the column, too.

Details

The custom == implementation for TLineInfo is removed, which means
that the default implementation (value equality) is used. exactEquals
is redundant now: its usages are replaced with == and the procedure
itself is removed.

Changed usage sites

The VM profiler implementation (vmprofiler) relied on the old equality
behaviour, as it uses TLineInfo as the key for a table that associates
profiler data with a source line. Here, TLineInfo usage is replaced
with the new SourceLinePosition tuple, which is a TLineInfo without
the column information.

For rendering the profiler data, a temporary TLineInfo instance is
created, but with the column set to -1. This means that the text output
now links to the source line without including a column position.

Other relevant usage sites

There are two other places where the different equality behaviour
causes a visible change in compiler behaviour, but that are not
adjusted because the new behaviour is better:

• with reporting "nil dereference" warnings (nilcheck.derefWarning):
  warnings are now reported one per line+column, instead of one per
  line
• providing error/warning context (msgs.getContext, "instantiated
  from" messages): if there are multiple surrounding instantiation
  contexts on the same line (but in different columns), they are now all
  shown, instead of only the first one

[zerbina]

Since it's the same as the lifted, you can remove the manual == implementation as a whole.

Also, could you elaborate on what you mean by "stop historical un-aware problem"? Apart from the simplification, which makes sense, what is the reason for this change?

[bung87]

Since it's the same as the lifted, you can remove the manual == implementation as a whole.

Also, could you elaborate on what you mean by "stop historical un-aware problem"? Apart from the simplification, which makes sense, what is the reason for this change?

== compare to line is anti-intuition

[zerbina]

== compare to line is anti-intuition

While I think the change is good, I don't think that the previous == behaviour is un-intuitive. The type is named TLineInfo, so the comparison returning true for two instances that point to the same line makes sense.

[bung87]

== compare to line is anti-intuition

While I think the change is good, I don't think that the previous == behaviour is un-intuitive. The type is named TLineInfo, so the comparison returning true for two instances that point to the same line makes sense.

while if user hover the == they can have a look to its definition, however if the expression use != it just show system template.

[zerbina]

while if user hover the == they can have a look to its definition, however if the expression use != it just show system template.

Hm, I'm not sure I understand the relation this has to the equality operation only considering the line number. Could you elaborate?

[bung87]

it's not a short path to track, how the user know the type have custom ==

template `!=`*(x, y: untyped): untyped =
  ## Unequals operator. This is a shorthand for `not (x == y)`.
  not (x == y)

oh, it has to be template ? not a operator?

[zerbina]

Are you saying that == for TLineInfo not considering the column information is un-intuitive because the != operator, as a consequeunce, is also not considering it?

To be clear, I'm only trying to understand your reasoning behind this change.

[bung87]

am saying without editor support I didn't aware there's custom == proc, the reason == implemented maybe just because msgs.getContext using !=

[zerbina]

Hm, okay. In my opinion, that could have also been mitigated via a less impactful change (e.g., by moving the equality operator and exactEquals into lineinfos and then documenting the quirk on TLineInfo).

In any way, have you verified that there are no usage sites left where the old equality behaviour is relied on?

[bung87]

I've found references on == like 5 results, msgs.getContext maybe the only place need old behavior for a little bit better performance

[zerbina]

For finding all usages or possible usage, you can annotate the old == procedure with .deprecated, which will show warnings at each usage site.

I've found two places where the changed == procedure causes a change in behaviour:

1. in vmprofiler.leaveImpl (the li notin data query)
2. in nilcheck.derefWarning (the n.info in ctx.warningLocations query)

The second one is maybe minor (only increasing the amount of warnings produced), but the first one is not, as the profiler wants to associate the time-taken with a line, and not a precise line + column.

[bung87]

nice! so if this going forward, only need fix vmprofiler.leaveImpl by using custom type without col I guess?

[zerbina]

Apart from renaming FileLinePar (my suggestions above), please also update the PR message. A detailed description on how a PR message should look like can be found in the contribution guidelines.

For this PR, please make sure:

• that the message and title reflect that that the PR effectively changes what a TLineInfo represents
• to detail the full impact (e.g., how the profiler output is different)
• that the motivation behind the change is clear and, ideally, why this way is preferred over a less impactful one

[zerbina]

The new PR message is much better than the previous one. However, there are still some things that I think need adjustments:

• as I mentioned, the removal of the two procedures is a detail -- it doesn't summarize the impact and thus neither belongs in the title nor summary. For example, to someone not familiar with what the == implementation did, the removal itself is meaningless
• it's not clear what "historical unawareness problems" means
• don't dismiss the impact of changes ("it can be ignored"), describe why it can be ignored

The title and summary should provide a broad overview of the impact and reasoning to both reviewers and future contributors. Language-level changes or changes to the user interface also usually go in this section.

The details section is for going into detail on the impact, what exactly changed, why it changed, what alternatives were considered (if any), etc.

[bung87]

updated, sorry for my pool English

[zerbina]

updated, sorry for my pool English

No worries, I and others can help you with writing commit messages.

I've updated the title and body according to my previous comments. In addition, the change doesn't only affect the performance of getContext, it also changes its behaviour. Please make sure to mention these things.

[zerbina]

/merge

[github-actions]

Merge requested by: @zerbina

Contents after the first section break of the PR description has been removed and preserved below:

---