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

Remove deriving(ToStr) #12412

Merged
merged 2 commits into from
Feb 24, 2014
Merged

Remove deriving(ToStr) #12412

merged 2 commits into from
Feb 24, 2014

Conversation

alexcrichton
Copy link
Member

This commit removes deriving(ToStr) in favor of deriving(Show), migrating all impls of ToStr to fmt::Show.

Most of the details can be found in the first commit message.

Closes #12477

@@ -106,11 +106,10 @@ impl<K: TotalOrd, V: TotalEq> TotalOrd for BTree<K, V> {
}
}

impl<K: ToStr + TotalOrd, V: ToStr> ToStr for BTree<K, V> {
impl<K: fmt::Show + TotalOrd, V: fmt::Show> fmt::Show for BTree<K, V> {
Copy link
Member

Choose a reason for hiding this comment

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

Is there a reason Show is being used as fmt::Show here?

Copy link
Member Author

Choose a reason for hiding this comment

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

Stylistically I prefer fmt::Show because otherwise you need to import fmt::{Show, Result, Formatter} everywhere.

@huonw
Copy link
Member

huonw commented Feb 22, 2014

Needs rebase.

@alexcrichton
Copy link
Member Author

Rebased.

fn to_str(&self) -> ~str { format!("{:?}", self.id) }
impl fmt::Show for RegionVid {
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
write!(f.buf, "{}", self.id)
Copy link
Member

Choose a reason for hiding this comment

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

General point: this write!(f.buf, "{}", x) pattern is pretty common, and ignores any formatting flags in f. Would it be worth having f.show(&x) that essentially does that macro, but paying attention to padding etc?

(Not necessary for this PR.)

Copy link
Member Author

Choose a reason for hiding this comment

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

I agree, wherever possible it's functionally nice to have foo.fmt(f). It's an unfortunate trait import, but I don't think it's that bad. I was just on autopilot plowing through these.

Copy link
Member

Choose a reason for hiding this comment

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

I was thinking a method on Formatter (so no trait import required), but that may be seen as "unfairly" prioritising Show.

@huonw
Copy link
Member

huonw commented Feb 24, 2014

r=me

This commit changes the ToStr trait to:

    impl<T: fmt::Show> ToStr for T {
        fn to_str(&self) -> ~str { format!("{}", *self) }
    }

The ToStr trait has been on the chopping block for quite awhile now, and this is
the final nail in its coffin. The trait and the corresponding method are not
being removed as part of this commit, but rather any implementations of the
`ToStr` trait are being forbidden because of the generic impl. The new way to
get the `to_str()` method to work is to implement `fmt::Show`.

Formatting into a `&mut Writer` (as `format!` does) is much more efficient than
`ToStr` when building up large strings. The `ToStr` trait forces many
intermediate allocations to be made while the `fmt::Show` trait allows
incremental buildup in the same heap allocated buffer. Additionally, the
`fmt::Show` trait is much more extensible in terms of interoperation with other
`Writer` instances and in more situations. By design the `ToStr` trait requires
at least one allocation whereas the `fmt::Show` trait does not require any
allocations.

Closes rust-lang#8242
Closes rust-lang#9806
This has been superseded by deriving(Show).

cc rust-lang#9806
bors added a commit that referenced this pull request Feb 24, 2014
This commit removes deriving(ToStr) in favor of deriving(Show), migrating all impls of ToStr to fmt::Show.

Most of the details can be found in the first commit message.

Closes #12477
@bors bors closed this Feb 24, 2014
@bors bors merged commit 8761f79 into rust-lang:master Feb 24, 2014
@alexcrichton alexcrichton deleted the deriving-show branch February 24, 2014 18:06
bors added a commit to rust-lang-ci/rust that referenced this pull request Jul 25, 2022
…ykril

fix: Retrigger visibility completion after parentheses

close rust-lang#12390

This PR add `(` to trigger_characters as discussed in original issue.

Some questions:

1. Is lsp's `ctx.trigger_character` from `params.context` is the same as `ctx.original_token` inside actually completions?
    1. If not what's the difference?
    2. if they are the same, it's unnecessary to pass it down from handler at all.
    3.  if they are the same, maybe we could parse it from fixture directly instead of using the `check_with_trigger_character` I added.
2. Some completion fixtures written as `($0)` ( https://github.com/rust-lang/rust-analyzer/blob/master/crates/ide-completion/src/tests/fn_param.rs#L105 as an example), If I understand correctly they are not invoked outside tests at all?
    1. using `ctx.original_token` directly would break these tests as well as parsing trigger_character from fixture for now.
    2. I think it make sense to allow `(` triggering these cases?
3. I hope this line up with rust-lang#12144
flip1995 pushed a commit to flip1995/rust that referenced this pull request Apr 4, 2024
make sure checked type implements `Try` trait when linting [`question_mark`]

(indirectly) fixes: rust-lang#12412 and fixes: rust-lang#11983

---

changelog: make sure checked type implements `Try` trait when linting [`question_mark`]
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.

ToStr should return the same as Show
4 participants