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.

Sign up for GitHub

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

Jump to bottom

Various problems calling ToStr on pointer types in rusti #7567

Closed
jedestep opened this issue Jul 3, 2013 · 2 comments
Closed

Various problems calling ToStr on pointer types in rusti #7567

jedestep opened this issue Jul 3, 2013 · 2 comments

Comments

@jedestep
Copy link
Contributor

jedestep commented Jul 3, 2013 

rusti> let f = @1;
rusti> f.to_str()
~"1"

So far so good.

rusti> let g = (@1, @2);
rusti> g.to_str()
error: failed to find am implementation of trait std::to_str::ToStr for @int

Seems like this should work out...

rusti> let h = (~[1], ~[2]);
rusti> h.to_str()
Segmentation fault: 11

Running on OSX 10.8 x86_64.
@alexcrichton
Copy link
Member

The first issue is related to #4869 where the implementations for @T and ~T were removed. I'm not sure if the debate ever settled on adding them back in to drop the sigil on the ToStr or not.

The second issue will be fixed by #7115 (blocked on windows failures)

@alexcrichton
Copy link
Member

#7115 has landed, this should be fixed now.

flip1995 pushed a commit to flip1995/rust that referenced this issue Sep 3, 2021
@bors
Auto merge of rust-lang#7568 - dtolnay-contrib:ifletelse, r=llogiq
5449e23 
Downgrade option_if_let_else to nursery

I believe that this lint's loose understanding of ownership (rust-lang#5822, rust-lang#6737) makes it unsuitable to be enabled by default in its current state, even as a pedantic lint.

Additionally the lint has known problems with type inference (rust-lang#6137), though I may be willing to consider this a non-blocker in isolation if it weren't for the ownership false positives.

A fourth false positive involving const fn: rust-lang#7567.

But on top of these, for me the biggest issue is I basically fully agree with rust-lang/rust-clippy#6137 (comment). In my experience this lint universally makes code worse even when the resulting code does compile.

---

changelog: remove [`option_if_let_else`] from default set of enabled lints
flip1995 pushed a commit to flip1995/rust that referenced this issue Sep 3, 2021
@bors
Auto merge of rust-lang#7573 - Jarcho:option_if_let_else, r=giraffate
fd30241 
Fix `option_if_let_else`

fixes: rust-lang#5822
fixes: rust-lang#6737
fixes: rust-lang#7567

The inference from rust-lang#6137 still exists so I'm not sure if this should be moved from the nursery. Before doing that though I'd almost want to see this split into two lints. One suggesting `map_or` and the other suggesting `map_or_else`.

`map_or_else` tends to have longer expressions for both branches so it doesn't end up much shorter than a match expression in practice. It also seems most people find it harder to read. `map_or` at least has the terseness benefit of being on one line most of the time, especially when the `None` branch is just a literal or path expression.

changelog: `break` and `continue` statments local to the would-be closure are allowed in `option_if_let_else`
changelog: don't lint in const contexts  in `option_if_let_else`
changelog: don't lint when yield expressions are used  in `option_if_let_else`
changelog: don't lint when the captures made by the would-be closure conflict with the other branch  in `option_if_let_else`
changelog: don't lint when a field of a local is used when the type could be pontentially moved from  in `option_if_let_else`
changelog: in some cases, don't lint when scrutinee expression conflicts with the captures of the would-be closure  in `option_if_let_else`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@alexcrichton @jedestep