Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

move locus calculation to separate function #334

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

Johann150
Copy link
Collaborator

This moves the locus calculation from RichDiagnostic::render to Diagnostic::locuses. Some questions to answer:

  • Is the implementation impact acceptable?
    The way I implemented this has some impacts on the existing API though: Because this way uses a BTreeMap keyed with the FileId, the FileId must now implement Ord instead of just PartialEq.

    This was the simplest and least overhead accumulating way to enable deduplication by file. Alternatively we could derive another arbirary ordering of the FileIds, e.g. by indices from a deduplicated Vec.

    I personally think this change is justified because

    • many library users make use of SimpleFiles, which is compatible and
    • any sensible candidates for FileId that I can think of and implement PartialEq also implement Ord.
  • Should this new function be added to the public API?
    I did not yet implement it this way, but it was suggested in Accessor for the location of a diagnostic #333. This would go towards better enabling "alternative" renderers.

@Johann150

This comment has been minimized.

@Johann150 Johann150 added the help wanted Extra attention is needed label Aug 12, 2021
@brendanzab
Copy link
Owner

I'm wondering if there is as way to do this without needing to allocate an intermediate BTreeMap for this? 🤔 That's the one thing that would give me pause I guess.

We might also be able to solve this better if we had some sort of intermediate 'resolved diagnostic' - something I'm hoping we can get to at some stage!

@Johann150
Copy link
Collaborator Author

The reason for using a BTreeMap was this comment

// NOTE: This could be made more efficient by using an associative
// data structure like a hashmap or B-tree, but we use a vector to
// preserve the order that unique files appear in the list of labels.

I would not call it an "intermediate BTreeMap" because its used afterwards, like the vector the above comment is referencing.

I don't see a way without allocating some data structure similar to this. We could do with a Vec but that does not come with the deduplication built in, and no advantages that I am aware of.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants