- 08 1月, 2015 18 次提交
-
-
由 Alex Crichton 提交于
-
由 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 提交于
result of using `ty::type_is_sized`
-
由 Daniel Grunwald 提交于
Fixes #20724.
-
由 Jorge Aparicio 提交于
-
由 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 提交于
feature gate net. fix typo in my feature-gate-box-expr.rs test.
-
由 Felix S. Klock II 提交于
-
由 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 提交于
-
由 Aaron Turon 提交于
-
由 Nick Cameron 提交于
Closes #20421 [breaking-change]
-
由 Jared Roesch 提交于
-
由 Niko Matsakis 提交于
Remember to check the name of the associated type being projected when searching the environment. Fixes #20651.
-
- 07 1月, 2015 15 次提交
-
-
由 Alex Crichton 提交于
-
由 Joseph Crail 提交于
I separated these changes out from the other commit to minimize issues with tests.
-
由 Piotr Czarnecki 提交于
Prevents breaking down `$name` tokens into separate `$` and `name`. Reports unknown macro variables. Fixes #18775 Fixes #18839 Fixes #15640
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
-
由 Corey Richardson 提交于
-
由 Sean McArthur 提交于
fmt::Show is for debugging, and can and should be implemented for all public types. This trait is used with `{:?}` syntax. There still exists #[derive(Show)]. fmt::String is for types that faithfully be represented as a String. Because of this, there is no way to derive fmt::String, all implementations must be purposeful. It is used by the default format syntax, `{}`. This will break most instances of `{}`, since that now requires the type to impl fmt::String. In most cases, replacing `{}` with `{:?}` is the correct fix. Types that were being printed specifically for users should receive a fmt::String implementation to fix this. Part of #20013 [breaking-change]
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Nick Cameron 提交于
-
由 Corey Richardson 提交于
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
[breaking-change]
-
由 Corey Richardson 提交于
-
由 Corey Richardson 提交于
See RFC 550 (https://github.com/rust-lang/rfcs/pull/550) for the motivation and details. If this breaks your code, add one of the listed tokens after the relevant non-terminal in your matcher. [breaking-change]
-
- 06 1月, 2015 7 次提交
-
-
由 Jared Roesch 提交于
Add check to ensure trait bounds are only placed on ty_param
-
由 Alex Crichton 提交于
-
由 Keegan McAllister 提交于
-
由 Keegan McAllister 提交于
-
由 Keegan McAllister 提交于
-
由 Keegan McAllister 提交于
-
由 Keegan McAllister 提交于
macro_rules! is like an item that defines a macro. Other items don't have a trailing semicolon, or use a paren-delimited body. If there's an argument for matching the invocation syntax, e.g. parentheses for an expr macro, then I think that applies more strongly to the *inner* delimiters on the LHS, wrapping the individual argument patterns.
-