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

Ensure lookup_source_file_idx has a sorted list of source files to use #115328

Closed
wants to merge 1 commit into from

Conversation

Zoxc
Copy link
Contributor

@Zoxc Zoxc commented Aug 28, 2023

This fixes a race condition where lookup_source_file_idx assumes that the list of source files is sorted, but that wasn't ensured with concurrent insertions of source files. This adds a new sorted source file list (sorted_files) dedicated for use in lookup_source_file_idx.

@rustbot
Copy link
Collaborator

rustbot commented Aug 28, 2023

r? @compiler-errors

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 28, 2023
@rust-log-analyzer

This comment has been minimized.


files.source_files.push(source_file.clone());
files.stable_id_to_source_file.insert(file_id, source_file.clone());
self.insert_source_file(&source_file, file_id);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was wondering if we could keep the same behaviour by locking files between allocate_address_space and the insertion. For instance:

  • allocate_address_space locks files, returns both the last file's end pos and the lock guard;
  • this line finalises the push to files and releases the lock.

This would get rid of used_address_space at the same time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would require holding the lock during SourceFile::new, which is expensive and rather complex.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also this moves lookup_source_file_idx from RwLock to Lock which is probably better performance wise. Not sure how hot it is for regular compilation though.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at SourceFile::new, I understand that it indexes all the lines in the file using the result of allocate_address_space.
Would using relative indexing inside the file avoid this dependency:

  • all indices in-file are done wrt. the beginning of the file;
  • the contents of SourceFile get independent of the absolute byte pos;
  • we can assign the start byte pos after SourceFile::new returns.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that would work, but I'm not looking to change a lot of source related function now.

SourceFile / SourceMap is very much due a refactoring to remove the mutable state, but it probably makes sense to wait until we can use the query system there.

@bors
Copy link
Contributor

bors commented Sep 5, 2023

☔ The latest upstream changes (presumably #115507) made this pull request unmergeable. Please resolve the merge conflicts.

@Zoxc
Copy link
Contributor Author

Zoxc commented Sep 7, 2023

Closed in favor of #115507.

@Zoxc Zoxc closed this Sep 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants