-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Remove deriving(ToStr) #12412
Conversation
@@ -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> { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Needs rebase. |
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) |
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
.
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
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
…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
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`]
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