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

no way to bubble up Send/Freeze through raw pointers #9509

Closed
thestinger opened this issue Sep 26, 2013 · 13 comments
Closed

no way to bubble up Send/Freeze through raw pointers #9509

thestinger opened this issue Sep 26, 2013 · 13 comments
Labels
P-medium Medium priority

Comments

@thestinger
Copy link
Contributor

You can't write a correct smart pointer or vector type in a library at the moment.

@thestinger
Copy link
Contributor Author

Nominating for the feature complete milestone.

@catamorphism
Copy link
Contributor

Can you give an example that doesn't work? @nikomatsakis thinks raw pointers already have the Send trait.

@nikomatsakis
Copy link
Contributor

It occurred to me that perhaps the point is that raw
pointers ALWAYS have the send trait, whereas you might
want something that is only sendable if it is a raw pointer
to a sendable thing (i.e., that simulates the behavior
of a ~ pointer).

@huonw
Copy link
Member

huonw commented Sep 27, 2013

@catamorphism Rc<T> is Freeze even when T is Send but not Freeze. e.g.

extern mod extra;
use std::cell::Cell;
use extra::rc::Rc;

fn is_freeze<T: Freeze>(_: T) {}

fn main() {
    // is_freeze(Cell::new(1)); // error: [...] Cell [...] does not fulfill Freeze

   is_freeze(Rc::from_send(Cell::new(1))); // compiles fine
}

(I believe @thestinger may be planning to remove from_send anyway, so this example may disappear.)

@thestinger
Copy link
Contributor Author

@nikomatsakis: yup, the point is that you can't make a smart pointer or vector type behaving like ~T or ~[T] in a library at the moment if you don't use ~ to allocate the memory

bors added a commit that referenced this issue Oct 11, 2013
I've left out a way to construct from a `Send` type until #9509 is resolved. I am confident that this interface can remain backwards compatible though, assuming we name the `Pointer` trait method `borrow`.

When there is a way to convert from `Send` (`from_send`), a future RAII-based `Mut` type can be used with this to implemented a mutable reference-counted pointer. For now, I've left around the `RcMut` type but it may drastically change or be removed.
@nikomatsakis
Copy link
Contributor

I was thinking more about this problem. This ties in with some discussions that @pnkfelix and I were having regarding tracing GC: In particular, if you have smart pointers like Rc, you would like them to be traced for any kind of tracing GC -- but that means traversing * pointers, which is not necessarily a safe thing to do. However, if we had some other kind of pointer, perhaps itself a smart pointer (actually a lang item), that basically indicated a wrapper pointer, then we could know that we ought to trace the pointer, and also know to treat it properly in the kind computation.

This argues for replacing * with Raw<T>, as has been proposed, since it would make it cleaner to have a family of raw pointers for different purposes.

@catamorphism
Copy link
Contributor

High but not 1.0

@nikomatsakis
Copy link
Contributor

It's possible that the correct fix for this is just to change how we compute the kinds for *T. After all, why should a *&Foo be sendable, or a *Cell be considered freezeable?

@nikomatsakis
Copy link
Contributor

If people REALLY want to hide the contents of their pointer from the type system, they can transmute to *i8 and back.

@thestinger
Copy link
Contributor Author

+1, going to close the KindMimic PR

@nikomatsakis
Copy link
Contributor

I can incorporate that change into PR #10158

@pnkfelix
Copy link
Member

Hmm it is not clear from the links above which PR (if any) has committed the fix I believe was settled on (namely changing kind computation to traverse even a *TypeExpr)

Posting to remind self to check on that later

@pnkfelix
Copy link
Member

Okay, the change landed in PR #10289 (which was the successful landing of many attempted PR's for #10157).

flip1995 pushed a commit to flip1995/rust that referenced this issue Oct 6, 2022
Fix sorting in ` cargo dev update_lints` script

changelog: none

The old code cloned and sorted `usable_lints` into `sorted_usable_lints`, but then failed to do anything with `sorted_usable_lints`.

This was discovered by my new `collection_is_never_read` lint (rust-lang#9267) that I'm working on!

Fix: I renamed the sorted vector to `usable_lints`.  Therefore it now gets used where the unsorted one was used previously.
flip1995 pushed a commit to flip1995/rust that referenced this issue Mar 10, 2023
…llogiq

Add `collection_is_never_read`

Fixes rust-lang#9267

`@flip1995` and `@llogiq,` I talked with you about this one at Rust Nation in London last week. :-)

This is my first contribution to Clippy, so lots of feedback would be greatly appreciated.

- \[ ] Followed [lint naming conventions][lint_naming]
- \[x] Added passing UI tests (including committed `.stderr` file)
- \[x] `cargo test` passes locally
- \[x] Executed `cargo dev update_lints`
- \[x] Added lint documentation
- \[x] Run `cargo dev fmt`

`dogfood` found one true positive (see rust-lang#9509) and no false positives.

`lintcheck` found no (true or false) positives, even when running on an extended set of crates.

---

changelog: new lint [`collection_is_never_read`]
[rust-lang#10415](rust-lang/rust-clippy#10415)
<!-- changelog_checked -->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P-medium Medium priority
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants