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

implement entry API for HashMap #17378

Merged
merged 2 commits into from
Sep 25, 2014
Merged

implement entry API for HashMap #17378

merged 2 commits into from
Sep 25, 2014

Conversation

Gankra
Copy link
Contributor

@Gankra Gankra commented Sep 18, 2014

Deprecates the find_or_* family of "internal mutation" methods on HashMap in
favour of the "external mutation" Entry API as part of RFC 60. Part of #17320,
but this still needs to be done on the rest of the maps. However they don't have
any internal mutation methods defined, so they can be done without deprecating
or breaking anything. Work on BTree is part of the complete rewrite in #17334.

The implemented API deviates from the API described in the RFC in two key places:

  • VacantEntry.set yields a mutable reference to the inserted element to avoid code
    duplication where complex logic needs to be done regardless of whether the entry
    was vacant or not.
  • OccupiedEntry.into_mut was added so that it is possible to return a reference
    into the map beyond the lifetime of the Entry itself, providing functional parity
    to VacantEntry.set.

This allows the full find_or_insert functionality to be implemented using this API.
A PR will be submitted to the RFC to amend this.

[breaking-change]

v as *mut _
};
robin_hood(bucket, ib, self.hash, self.key, value);
unsafe { &mut *val_ptr }
Copy link
Contributor

Choose a reason for hiding this comment

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

Unfortunately, this would become the only instance of unsafe in this module, even though it's correct. I think robin_hood already returns the value we need.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh wow, I completely missed that. Perfect!

@Gankra Gankra force-pushed the hashmap-entry branch 3 times, most recently from 5eca516 to 6c255a8 Compare September 20, 2014 15:13
@Gankra
Copy link
Contributor Author

Gankra commented Sep 20, 2014

This should be good-to-go now.

@aturon
Copy link
Member

aturon commented Sep 22, 2014

f? @pczarn

Can you do an initial review of this PR? Given your recent revamp of HashMap, you're probably the most qualified person to do so :-)

idx_push(&mut *table.table.borrow_mut(), Mark(m, ctxt));

*table.mark_memo.borrow_mut().find_or_insert_with(key, new_ctxt)
* match table.mark_memo.borrow_mut().entry(key) {
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: non-obvious derefs.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah... I started going for literal translations of the old code, and dereffing matches was one of those weird consequences. You would make a temporary variable to deref, then?

@pczarn
Copy link
Contributor

pczarn commented Sep 23, 2014

I have already done a review. I went through the impl once more. The naming is not ideal, in particular fn set does more than one might expect (e.g. replacing swapping out the value). Setting a Vacant entry could give back an Occupied one. But these aren't pressing issues since the API is experimental. Overall, this addition maps nicely to the internals and exposes the right amount of functionality.

@Gankra
Copy link
Contributor Author

Gankra commented Sep 24, 2014

@aturon Does that new commit resolve your issues? If so, I'll rebase.

@aturon
Copy link
Member

aturon commented Sep 24, 2014

@gankro Yes, that's excellent! Please squash/rebase, and then I'll r+

@Gankra
Copy link
Contributor Author

Gankra commented Sep 24, 2014

Done.

@aturon
Copy link
Member

aturon commented Sep 24, 2014

@gankro weird about the deprecation failure. Were you doing make check locally, or something else?

@Gankra
Copy link
Contributor Author

Gankra commented Sep 24, 2014

Ah, I ran make check-collections, but hashmap is in std.

Deprecates the `find_or_*` family of "internal mutation" methods on `HashMap` in
favour of the "external mutation" Entry API as part of RFC 60. Part of rust-lang#17320,
although this still needs to be done on the rest of the maps, they don't have
any internal mutation methods defined, so they can be done without deprecating
or breaking anything. Work on `BTree`'s is part of the complete rewrite in rust-lang#17334.

The implemented API deviates from the API described in the RFC in two key places:

* `VacantEntry.set` yields a mutable reference to the inserted element to avoid code
duplication where complex logic needs to be done *regardless* of whether the entry
was vacant or not.
* `OccupiedEntry.into_mut` was added so that it is possible to return a reference
into the map beyond the lifetime of the Entry itself, providing functional parity
to `VacantEntry.set`.

This allows the full find_or_insert functionality to be implemented using this API.
A PR will be submitted to the RFC to amend this.

[breaking-change]
@Gankra
Copy link
Contributor Author

Gankra commented Sep 25, 2014

sigh TIL that check-std doesn't check the doccomment code examples... and that deprecation is checked there too.

@aturon This time FOR REALS THOUGH. (please bors, please)

bors added a commit that referenced this pull request Sep 25, 2014
Deprecates the `find_or_*` family of "internal mutation" methods on `HashMap` in
favour of the "external mutation" Entry API as part of RFC 60. Part of #17320,
but this still needs to be done on the rest of the maps. However they don't have
any internal mutation methods defined, so they can be done without deprecating
or breaking anything. Work on `BTree` is part of the complete rewrite in #17334.

The implemented API deviates from the API described in the RFC in two key places:

* `VacantEntry.set` yields a mutable reference to the inserted element to avoid code
duplication where complex logic needs to be done *regardless* of whether the entry
was vacant or not.
* `OccupiedEntry.into_mut` was added so that it is possible to return a reference
into the map beyond the lifetime of the Entry itself, providing functional parity
to `VacantEntry.set`.

This allows the full find_or_insert functionality to be implemented using this API.
A PR will be submitted to the RFC to amend this.

[breaking-change]
@bors bors closed this Sep 25, 2014
@bors bors merged commit fe8a413 into rust-lang:master Sep 25, 2014
lnicola pushed a commit to lnicola/rust that referenced this pull request Jun 23, 2024
fix: ensure that the parent of a SourceRoot cannot be itself

fix rust-lang#17378.

In `FileSetConfig.map`, different roots might be mapped to the same `root_id` due to deduplication in `ProjectFolders::new`:

```rust
// Example from rustup
/Users/roife/code/rustup/target/debug/build/rustup-863a063426b56c51/out
/Users/roife/code/rustup
```

In `source_root_parent_map`, r-a might encounter paths where their SourceRootId (i.e. `root_id`) is identical, yet one the them is the parent of the another. This situation can cause the `root_id` to be its own parent, potentially leading to an infinite loop.

This PR resolves such cases by adding a check.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants