- 06 1月, 2015 1 次提交
-
-
由 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.
-
- 04 1月, 2015 2 次提交
-
-
由 Chase Southwood 提交于
Due to the `#[deriving]` -> `#[derive]` switch.
-
由 Jorge Aparicio 提交于
-
- 22 12月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
-
- 19 12月, 2014 1 次提交
-
-
由 Patrick Walton 提交于
followed by a semicolon. This allows code like `vec![1i, 2, 3].len();` to work. This breaks code that uses macros as statements without putting semicolons after them, such as: fn main() { ... assert!(a == b) assert!(c == d) println(...); } It also breaks code that uses macros as items without semicolons: local_data_key!(foo) fn main() { println("hello world") } Add semicolons to fix this code. Those two examples can be fixed as follows: fn main() { ... assert!(a == b); assert!(c == d); println(...); } local_data_key!(foo); fn main() { println("hello world") } RFC #378. Closes #18635. [breaking-change]
-
- 14 12月, 2014 2 次提交
-
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
- 09 12月, 2014 1 次提交
-
-
由 Niko Matsakis 提交于
This change makes the compiler no longer infer whether types (structures and enumerations) implement the `Copy` trait (and thus are implicitly copyable). Rather, you must implement `Copy` yourself via `impl Copy for MyType {}`. A new warning has been added, `missing_copy_implementations`, to warn you if a non-generic public type has been added that could have implemented `Copy` but didn't. For convenience, you may *temporarily* opt out of this behavior by using `#![feature(opt_out_copy)]`. Note though that this feature gate will never be accepted and will be removed by the time that 1.0 is released, so you should transition your code away from using it. This breaks code like: #[deriving(Show)] struct Point2D { x: int, y: int, } fn main() { let mypoint = Point2D { x: 1, y: 1, }; let otherpoint = mypoint; println!("{}{}", mypoint, otherpoint); } Change this code to: #[deriving(Show)] struct Point2D { x: int, y: int, } impl Copy for Point2D {} fn main() { let mypoint = Point2D { x: 1, y: 1, }; let otherpoint = mypoint; println!("{}{}", mypoint, otherpoint); } This is the backwards-incompatible part of #13231. Part of RFC #3. [breaking-change]
-
- 04 12月, 2014 2 次提交
-
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
- 26 11月, 2014 1 次提交
-
-
由 Steve Klabnik 提交于
This is considered good convention.
-
- 24 11月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
This change applies the conventions to unwrap listed in [RFC 430][rfc] to rename non-failing `unwrap` methods to `into_inner`. This is a breaking change, but all `unwrap` methods are retained as `#[deprecated]` for the near future. To update code rename `unwrap` method calls to `into_inner`. [rfc]: https://github.com/rust-lang/rfcs/pull/430 [breaking-change] Closes #13159 cc #19091
-
- 19 11月, 2014 3 次提交
-
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 Jakub Bukaj 提交于
Fixes #19069.
-
- 18 11月, 2014 2 次提交
-
-
由 Niko Matsakis 提交于
Move trans, back, driver, and back into a new crate, rustc_trans. Reduces memory usage significantly and opens opportunities for more parallel compilation.
-
由 Aaron Turon 提交于
This commit handles the fallout from deprecating `_with` and `_equiv` methods.
-
- 17 11月, 2014 1 次提交
-
-
由 Steven Fackler 提交于
This breaks code that referred to variant names in the same namespace as their enum. Reexport the variants in the old location or alter code to refer to the new locations: ``` pub enum Foo { A, B } fn main() { let a = A; } ``` => ``` pub use self::Foo::{A, B}; pub enum Foo { A, B } fn main() { let a = A; } ``` or ``` pub enum Foo { A, B } fn main() { let a = Foo::A; } ``` [breaking-change]
-
- 16 11月, 2014 1 次提交
-
-
由 Steven Fackler 提交于
Struct variant field visibility is now inherited. Remove `pub` keywords from declarations. Closes #18641 [breaking-change]
-
- 10 11月, 2014 1 次提交
-
-
由 Ariel Ben-Yehuda 提交于
-
- 07 11月, 2014 1 次提交
-
-
由 Alexis Beingessner 提交于
-
- 04 11月, 2014 1 次提交
-
-
由 Ariel Ben-Yehuda 提交于
None of them would break by implementation-defined struct layout, but one would break with strict lifetime aliasing, and the rest are just ugly code.
-
- 31 10月, 2014 2 次提交
-
-
由 Jorge Aparicio 提交于
- The signature of the `*_equiv` methods of `HashMap` and similar structures have changed, and now require one less level of indirection. Change your code from: ``` hashmap.find_equiv(&"Hello"); hashmap.find_equiv(&&[0u8, 1, 2]); ``` to: ``` hashmap.find_equiv("Hello"); hashmap.find_equiv(&[0u8, 1, 2]); ``` - The generic parameter `T` of the `Hasher::hash<T>` method have become `Sized?`. Downstream code must add `Sized?` to that method in their implementations. For example: ``` impl Hasher<FnvState> for FnvHasher { fn hash<T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ } } ``` must be changed to: ``` impl Hasher<FnvState> for FnvHasher { fn hash<Sized? T: Hash<FnvState>>(&self, t: &T) -> u64 { /* .. */ } // ^^^^^^ } ``` [breaking-change]
-
由 Alex Crichton 提交于
-
- 30 10月, 2014 1 次提交
-
-
由 P1start 提交于
These lints are allow by default because they are sometimes too sensitive.
-
- 29 10月, 2014 1 次提交
-
-
由 Steve Klabnik 提交于
https://github.com/rust-lang/rfcs/pull/221 The current terminology of "task failure" often causes problems when writing or speaking about code. You often want to talk about the possibility of an operation that returns a Result "failing", but cannot because of the ambiguity with task failure. Instead, you have to speak of "the failing case" or "when the operation does not succeed" or other circumlocutions. Likewise, we use a "Failure" header in rustdoc to describe when operations may fail the task, but it would often be helpful to separate out a section describing the "Err-producing" case. We have been steadily moving away from task failure and toward Result as an error-handling mechanism, so we should optimize our terminology accordingly: Result-producing functions should be easy to describe. To update your code, rename any call to `fail!` to `panic!` instead. Assuming you have not created your own macro named `panic!`, this will work on UNIX based systems: grep -lZR 'fail!' . | xargs -0 -l sed -i -e 's/fail!/panic!/g' You can of course also do this by hand. [breaking-change]
-
- 28 10月, 2014 1 次提交
-
-
由 Aaron Turon 提交于
-
- 24 10月, 2014 1 次提交
-
-
由 P1start 提交于
Closes #17792.
-
- 20 10月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
Spring cleaning is here! In the Fall! This commit removes quite a large amount of deprecated functionality from the standard libraries. I tried to ensure that only old deprecated functionality was removed. This is removing lots and lots of deprecated features, so this is a breaking change. Please consult the deprecation messages of the deleted code to see how to migrate code forward if it still needs migration. [breaking-change]
-
- 15 10月, 2014 2 次提交
-
-
由 Aaron Turon 提交于
Since a large number of lints are being renamed for RFC 344, this commit adds some basic deprecation/renaming functionality to the pluggable lint system. It allows a simple mapping of old to new names, and can warn when old names are being used. This change needs to be rolled out in stages. In this commit, the deprecation warning is commented out, but the old name is forwarded to the new one. Once the commit lands and we have generated a new snapshot of the compiler, we can add the deprecation warning and rename all uses of the lints in the rust codebase.
-
由 Aaron Turon 提交于
RFC 344 proposes a set of naming conventions for lints. This commit renames existing lints to follow the conventions. Use the following sed script to bring your code up to date: ``` s/unnecessary_typecast/unused_typecasts/g s/unsigned_negate/unsigned_negation/g s/type_limits/unused_comparisons/g s/type_overflow/overflowing_literals/g s/ctypes/improper_ctypes/g s/owned_heap_memory/box_pointers/g s/unused_attribute/unused_attributes/g s/path_statement/path_statements/g s/unused_must_use/unused_must_use/g s/unused_result/unused_results/g s/non_uppercase_statics/non_upper_case_globals/g s/unnecessary_parens/unused_parens/g s/unnecessary_import_braces/unused_import_braces/g s/unused_unsafe/unused_unsafe/g s/unsafe_block/unsafe_blocks/g s/unused_mut/unused_mut/g s/unnecessary_allocation/unused_allocation/g s/missing_doc/missing_docs/g s/unused_imports/unused_imports/g s/unused_extern_crate/unused_extern_crates/g s/unnecessary_qualification/unused_qualifications/g s/unrecognized_lint/unknown_lints/g s/unused_variable/unused_variables/g s/dead_assignment/unused_assignments/g s/unknown_crate_type/unknown_crate_types/g s/variant_size_difference/variant_size_differences/g s/transmute_fat_ptr/fat_ptr_transmutes/g ``` Closes #16545 Closes #17932 Due to deprecation, this is a: [breaking-change]
-
- 10 10月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
-
- 03 10月, 2014 1 次提交
-
-
由 P1start 提交于
-
- 18 9月, 2014 1 次提交
-
-
由 Patrick Walton 提交于
The implementation essentially desugars during type collection and AST type conversion time into the parameter scheme we have now. Only fully qualified names--e.g. `<T as Foo>::Bar`--are supported.
-
- 17 9月, 2014 1 次提交
-
-
由 Aaron Turon 提交于
-
- 14 9月, 2014 1 次提交
-
-
由 Eduard Burtescu 提交于
-
- 12 9月, 2014 3 次提交
-
-
由 Eduard Burtescu 提交于
-
由 Eduard Burtescu 提交于
-
由 Victor Berger 提交于
-
- 10 9月, 2014 1 次提交
-
-
由 OGINO Masanori 提交于
The lint checks any unnecessary braces around one imported item like `use std::num::{abs};`. Signed-off-by: NOGINO Masanori <masanori.ogino@gmail.com>
-