-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Migrate std::fmt to core::fmt #14115
Conversation
|
||
// Implementations of the core formatting traits | ||
|
||
impl<T: Show> Show for @T { |
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.
Sure would be nice if we could get rid of this one. I wonder how much work it would be? (Shouldn't be done in this series of commits as it's very long as is.)
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.
We'd have to either remove @
as a type in the language, deprecate all usage of @
in favor of Gc<T>
, or be able to designate that some other crate "owns" @
to define traits on it. I'm kinda hoping for the second option!
The Float trait in libstd is quite a large trait which has dependencies on cmath (libm) and such, which libcore cannot satisfy. It also has many functions that libcore can implement, however, as LLVM has intrinsics or they're just bit twiddling. This commit moves what it can of the Float trait from the standard library into libcore to allow floats to be usable in the core library. The remaining functions are now resident in a FloatMath trait in the standard library (in the prelude now). Previous code which was generic over just the Float trait may now need to be generic over the FloatMath trait. [breaking-change]
This commit moves all possible functionality from the standard library's string formatting utilities into the core library. This is a breaking change, due to a few tweaks in the semantics of formatting: 1. In order to break the dependency on the std::io module, a new trait, FormatWriter was introduced in core::fmt. This is the trait which is used (instead of Writer) to format data into a stream. 2. The new FormatWriter trait has one method, write(), which takes some bytes and can return an error, but the error contains very little information. The intent for this trait is for an adaptor writer to be used around the standard library's Writer trait. 3. The fmt::write{,ln,_unsafe} methods no longer take &mut io::Writer, but rather &mut FormatWriter. Since this trait is less common, all functions were removed except fmt::write, and it is not intended to be invoked directly. The main API-breaking change here is that the fmt::Formatter structure will no longer expose its `buf` field. All previous code writing directly to `f.buf` using writer methods or the `write!` macro will now instead use `f` directly. The Formatter object itself implements the `Writer` trait itself for convenience, although it does not implement the `FormatWriter` trait. The fallout of these changes will be in the following commits. [breaking-change]
Now that std::fmt is in libcore, it's possible to implement this as an inherit method rather than through extension traits. This commit also tweaks the failure interface of libcore to libstd to what it should be, one method taking &fmt::Arguments
With std::fmt having migrated, the failure macro can be expressed in its full glory.
This is used quite extensively by core::fmt
These were temporarily moved to explicit implementations, but now that fmt is in core it's possible to derive again.
This new method, write_fmt(), is the one way to write a formatted list of arguments into a Writer stream. This has a special adaptor to preserve errors which occur on the writer. All macros will be updated to use this method explicitly.
Currently, the format_args!() macro takes as its first argument an expression which is the callee of an ExprCall. This means that if format_args!() is used with calling a method a closure must be used. Consider this code, however: format_args!(|args| { foo.writer.write_fmt(args) }, "{}", foo.field) The closure borrows the entire `foo` structure, disallowing the later borrow of `foo.field`. To preserve the semantics of the `write!` macro, it is also impossible to borrow specifically the `writer` field of the `foo` structure because it must be borrowed mutably, but the `foo` structure is not guaranteed to be mutable itself. This new macro is invoked like: format_args_method!(foo.writer, write_fmt, "{}", foo.field) This macro will generate an ExprMethodCall which allows the borrow checker to understand that `writer` and `field` should be borrowed separately. This macro is not strictly necessary, with DST or possibly UFCS other workarounds could be used. For now, though, it looks like this is required to implement the `write!` macro.
These are reimplemented using the new `core::fmt` module.
1. Wherever the `buf` field of a `Formatter` was used, the `Formatter` is used instead. 2. The usage of `write_fmt` is minimized as much as possible, the `write!` macro is preferred wherever possible. 3. Usage of `fmt::write` is minimized, favoring the `write!` macro instead.
This is a migration of the std::{f32, f64}::to_str* functionality to the core library. This removes the growable `Vec` used in favor of a large stack buffer. The maximum base 10 exponent for f64 is 308, so a stack buffer of 512 bytes should be sufficient to store all floats.
In an attempt to phase out the std::num::strconv module's string formatting functionality, this commit reimplements some provided methods for formatting integers on top of format!() instead of the custom (and slower) implementation inside of num::strconv. Primarily, this deprecates int_to_str_bytes_common
This was a more difficult change than I thought it would be, and it is unfortunately a breaking change rather than a drop-in replacement. Most of the rationale can be found in the third commit. cc #13851
This was a more difficult change than I thought it would be, and it is unfortunately a breaking change rather than a drop-in replacement. Most of the rationale can be found in the third commit.
cc #13851