- 08 1月, 2015 40 次提交
-
-
由 Alex Crichton 提交于
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
-
由 Nick Cameron 提交于
-
由 Felix S. Klock II 提交于
-
由 Huon Wilson 提交于
This is a [breaking-change]. Change impl<T> Foo<T> { fn bar<T>(... to (for example) impl<T> Foo<T> { fn bar<U>(... Per RFC 459. Closes #19390.
-
由 Niko Matsakis 提交于
Fixes #20535.
-
由 Niko Matsakis 提交于
result of using `ty::type_is_sized`
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Daniel Grunwald 提交于
Fixes #20724.
-
由 Felix S. Klock II 提交于
-
由 Jorge Aparicio 提交于
-
由 Tom Jakubowski 提交于
e.g. `Foo<Output=A>` This does not work cross-crate unfortunately. Part of #20646
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
-
由 Jonathan Reem 提交于
This bound is probably unintentional and is unnecessarily constricting. To facilitate this change, it was also necessary to modify resolve to recurse on and resolve type parameters in extern { } blocks. This fixes an ICE when using bounds on type parameters during the declaration of intrinsics. This also adds tests for TypeId on both Sized and Unsized tests as well as a test for using type parameters and bounds in extern { } blocks.
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
feature gate net. fix typo in my feature-gate-box-expr.rs test.
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
Specifically added to the test, librustc_trans, librustc_typeck crates.
-
由 Felix S. Klock II 提交于
To avoid using the feauture, change uses of `box <expr>` to `Box::new(<expr>)` alternative, as noted by the feature gate message. (Note that box patterns have no analogous trivial replacement, at least not in general; you need to revise the code to do a partial match, deref, and then the rest of the match.) [breaking-change]
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Brian Anderson 提交于
This partially implements the feature staging described in the [release channel RFC][rc]. It does not yet fully conform to the RFC as written, but does accomplish its goals sufficiently for the 1.0 alpha release. It has three primary user-visible effects: * On the nightly channel, use of unstable APIs generates a warning. * On the beta channel, use of unstable APIs generates a warning. * On the beta channel, use of feature gates generates a warning. Code that does not trigger these warnings is considered 'stable', modulo pre-1.0 bugs. Disabling the warnings for unstable APIs continues to be done in the existing (i.e. old) style, via `#[allow(...)]`, not that specified in the RFC. I deem this marginally acceptable since any code that must do this is not using the stable dialect of Rust. Use of feature gates is itself gated with the new 'unstable_features' lint, on nightly set to 'allow', and on beta 'warn'. The attribute scheme used here corresponds to an older version of the RFC, with the `#[staged_api]` crate attribute toggling the staging behavior of the stability attributes, but the user impact is only in-tree so I'm not concerned about having to make design changes later (and I may ultimately prefer the scheme here after all, with the `#[staged_api]` crate attribute). Since the Rust codebase itself makes use of unstable features the compiler and build system to a midly elaborate dance to allow it to bootstrap while disobeying these lints (which would otherwise be errors because Rust builds with `-D warnings`). This patch includes one significant hack that causes a regression. Because the `format_args!` macro emits calls to unstable APIs it would trigger the lint. I added a hack to the lint to make it not trigger, but this in turn causes arguments to `println!` not to be checked for feature gates. I don't presently understand macro expansion well enough to fix. This is bug #20661. Closes #16678 [rc]: https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md
-
由 Alex Crichton 提交于
This commit performs a pass over the implementations of the new `String` trait in the formatting module. Some implementations were removed as a conservative move pending an upcoming convention about `String` implementations, and some were added in order to retain consistency across the libraries. Specifically: * All "smart pointers" implement `String` now, adding missing implementations for `Arc` and `Rc`. * The `Vec<T>` and `[T]` types no longer implement `String`. * The `*const T` and `*mut T` type no longer implement `String`. * The `()` type no longer implements `String`. * The `Path` type's `Show` implementation does not surround itself with `Path {}` (a minor tweak). All implementations of `String` in this PR were also marked `#[stable]` to indicate that the types will continue to implement the `String` trait regardless of what it looks like.
-
由 Huon Wilson 提交于
Opt-in built-in traits allowed one to explicitly implement both `Drop` and `Copy` for a type. This can theoretically make some sense, but the current implementation means it is codegened totally incorrectly which can lead to memory unsafety, so this feature is disabled for now. Fixes #20126.
-
由 Jorge Aparicio 提交于
-
由 Felix S. Klock II 提交于
-
由 Nick Cameron 提交于
Technically this is a [breaking-change] but it probably shouldn't affect your code. Closes #20256
-
由 Nick Cameron 提交于
-
由 Jorge Aparicio 提交于
-
由 Alex Crichton 提交于
This commit performs a pass over the `std::macros` module, applying stability attributes where necessary. In particular, this audits macros for patterns such as: * Standard use of forward-to-format-args via `$($arg:tt)*` (or `+`) * Prevent macro-defined identifiers from leaking into expression arguments as hygiene is not perfectly implemented. * Wherever possible, `$crate` is used now. Specifically, the following actions were taken: * The `std::macros` module itself is no longer public. * The `panic!` macro is stable * The `assert!` macro is stable * The `assert_eq!` macro is stable * The `debug_assert!` macro is stable * The `debug_assert_eq!` macro is stable * The `unreachable!` macro is stable after removing the extra forms to bring the definition in line with the `unimplemented!` macro. * The `try!` macro is stable * The `vec!` macro is stable [breaking-change]
-
由 Thiago Pontes 提交于
-
由 Dabo Ross 提交于
This changes a line that has `\n#[stable]}` to instead have `}\n#[stable]`
-
由 Alex Crichton 提交于
This commit aims to prepare the `std::hash` module for alpha by formalizing its current interface whileholding off on adding `#[stable]` to the new APIs. The current usage with the `HashMap` and `HashSet` types is also reconciled by separating out composable parts of the design. The primary goal of this slight redesign is to separate the concepts of a hasher's state from a hashing algorithm itself. The primary change of this commit is to separate the `Hasher` trait into a `Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was actually just a factory for various states, but hashing had very little control over how these states were used. Additionally the old `Hasher` trait was actually fairly unrelated to hashing. This commit redesigns the existing `Hasher` trait to match what the notion of a `Hasher` normally implies with the following definition: trait Hasher { type Output; fn reset(&mut self); fn finish(&self) -> Output; } This `Hasher` trait emphasizes that hashing algorithms may produce outputs other than a `u64`, so the output type is made generic. Other than that, however, very little is assumed about a particular hasher. It is left up to implementors to provide specific methods or trait implementations to feed data into a hasher. The corresponding `Hash` trait becomes: trait Hash<H: Hasher> { fn hash(&self, &mut H); } The old default of `SipState` was removed from this trait as it's not something that we're willing to stabilize until the end of time, but the type parameter is always required to implement `Hasher`. Note that the type parameter `H` remains on the trait to enable multidispatch for specialization of hashing for particular hashers. Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is simply used as part `derive` and the implementations for all primitive types. With these definitions, the old `Hasher` trait is realized as a new `HashState` trait in the `collections::hash_state` module as an unstable addition for now. The current definition looks like: trait HashState { type Hasher: Hasher; fn hasher(&self) -> Hasher; } The purpose of this trait is to emphasize that the one piece of functionality for implementors is that new instances of `Hasher` can be created. This conceptually represents the two keys from which more instances of a `SipHasher` can be created, and a `HashState` is what's stored in a `HashMap`, not a `Hasher`. Implementors of custom hash algorithms should implement the `Hasher` trait, and only hash algorithms intended for use in hash maps need to implement or worry about the `HashState` trait. The entire module and `HashState` infrastructure remains `#[unstable]` due to it being recently redesigned, but some other stability decision made for the `std::hash` module are: * The `Writer` trait remains `#[experimental]` as it's intended to be replaced with an `io::Writer` (more details soon). * The top-level `hash` function is `#[unstable]` as it is intended to be generic over the hashing algorithm instead of hardwired to `SipHasher` * The inner `sip` module is now private as its one export, `SipHasher` is reexported in the `hash` module. And finally, a few changes were made to the default parameters on `HashMap`. * The `RandomSipHasher` default type parameter was renamed to `RandomState`. This renaming emphasizes that it is not a hasher, but rather just state to generate hashers. It also moves away from the name "sip" as it may not always be implemented as `SipHasher`. This type lives in the `std::collections::hash_map` module as `#[unstable]` * The associated `Hasher` type of `RandomState` is creatively called... `Hasher`! This concrete structure lives next to `RandomState` as an implemenation of the "default hashing algorithm" used for a `HashMap`. Under the hood this is currently implemented as `SipHasher`, but it draws an explicit interface for now and allows us to modify the implementation over time if necessary. There are many breaking changes outlined above, and as a result this commit is a: [breaking-change]
-