- 19 2月, 2015 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 14 2月, 2015 1 次提交
-
-
由 Steve Klabnik 提交于
-
- 12 2月, 2015 1 次提交
-
-
由 Kevin Butler 提交于
enumerations that implement the `Drop` trait. This breaks code like: struct Struct { f: String, g: String, } impl Drop for Struct { ... } fn main() { let x = Struct { ... }; drop(x); x.f = ...; } Change this code to not create partially-initialized structures. For example: struct Struct { f: String, g: String, } impl Drop for Struct { ... } fn main() { let x = Struct { ... }; drop(x); x = Struct { f: ..., g: ..., } } Closes #18571. [breaking-change] ---- (Joint authorship by pcwalton and Ryman; thanks all!)
-
- 11 2月, 2015 1 次提交
-
-
由 Steve Klabnik 提交于
This is super black magic internals at the moment, but having it somewhere semi-public seems good. The current versions weren't being rendered, and they'll be useful for some people. Fixes #21281
-
- 07 2月, 2015 1 次提交
-
-
由 Felix S. Klock II 提交于
No longer legal: `fn foo(a: [D; 5]) { drop(a); a[2] = D::new(); }`; one must first initialize the entirety of `a` before assigning to its individual elements. No longer legal: `fn foo(arr: [D; 5]) -> D { arr[2] }`, unless `D` implements `Copy`. This "move out-from" restriction only affects `expr[i]`, and not destructuring (e.g. `f([a, b, c]: Array) { ... }`). uses mem_categorization to distinguish destructuring-bind from array indexing. See discussion on RFC PR 533. [breaking-change]
-
- 06 2月, 2015 3 次提交
-
-
由 GuillaumeGomez 提交于
-
由 GuillaumeGomez 提交于
-
由 Jorge Aparicio 提交于
-
- 05 2月, 2015 1 次提交
-
-
由 Jorge Aparicio 提交于
-
- 04 2月, 2015 2 次提交
-
-
由 Steven Fackler 提交于
This was particularly helpful in the time just after OIBIT's implementation to make sure things that were supposed to be Copy continued to be, but it's now creates a lot of noise for types that intentionally don't want to be Copy.
-
由 Niko Matsakis 提交于
upgrade the inference based on expected type so that it is able to infer the fn kind in isolation even if the full signature is not available (and we could perhaps do better still in some cases, such as extracting just the types of the arguments but not the return value).
-
- 29 1月, 2015 1 次提交
-
-
由 Jorge Aparicio 提交于
-
- 27 1月, 2015 1 次提交
-
-
由 Edward Wang 提交于
It was considered to be impossible but actually it can happen for nested closures. Also, because there must be nested closures when this happens, we can use more targeted help message. Closes #21390 Closes #21600
-
- 26 1月, 2015 1 次提交
-
-
由 Eduard Burtescu 提交于
-
- 08 1月, 2015 2 次提交
-
-
由 Niko Matsakis 提交于
more modern terminology and update tests accordingly.
-
由 Jorge Aparicio 提交于
-
- 07 1月, 2015 3 次提交
-
-
由 Nick Cameron 提交于
-
由 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]
-
由 Nick Cameron 提交于
-
- 06 1月, 2015 2 次提交
-
-
由 Jorge Aparicio 提交于
-
由 Keegan McAllister 提交于
-
- 04 1月, 2015 2 次提交
-
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
- 03 1月, 2015 1 次提交
-
-
由 Niko Matsakis 提交于
`UnboxedClosureTyper`. This requires adding a `tcx` field to `ParameterEnvironment` but generally simplifies everything since we only need to pass along an `UnboxedClosureTyper` or `Typer`.
-
- 01 1月, 2015 1 次提交
-
-
由 Jorge Aparicio 提交于
-
- 25 12月, 2014 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 22 12月, 2014 1 次提交
-
-
由 Alex Crichton 提交于
-
- 19 12月, 2014 2 次提交
-
-
由 Jorge Aparicio 提交于
-
由 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 1 次提交
-
-
由 Niko Matsakis 提交于
language. Recommend `move||` instead.
-
- 13 12月, 2014 1 次提交
-
-
由 Niko Matsakis 提交于
-
- 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]
-
- 27 11月, 2014 1 次提交
-
-
由 Steve Klabnik 提交于
Sister pull request of https://github.com/rust-lang/rust/pull/19288, but for the other style of block doc comment.
-
- 25 11月, 2014 5 次提交
-
-
由 Felix S. Klock II 提交于
Includes differentiation between assigned_fragments and moved_fragments, support for all-but-one array fragments, and instrumentation to print out the moved/assigned/unmmoved/parents for each function, factored out into separate submodule.
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
To make this clean, refactored old `LoanPath` enum into a `LoanPath` struct with a `ty::t` and a newly-added `LoanPathVariant` enum. This enabled me to get rid of the ugly and fragile `LoanPath::to_type` method, and I can probably also get rid of other stuff that was supporting it, maybe.
-
由 Felix S. Klock II 提交于
`LpDowncast` carries the `DefId` of the variant itself. To support this, added the enum variant `DefId` to the `cat_downcast` variant in `mem_categorization::categorization`. (updated to fix mem_categorization to handle downcast of enum struct-variants properly.)
-
- 20 11月, 2014 2 次提交
-
-
由 Felix S. Klock II 提交于
(Previously, statically identifiable scopes/regions were solely identified with NodeId's; this refactoring prepares for a future where that 1:1 correspondence does not hold.)
-
由 Niko Matsakis 提交于
Merge the ExprFnBlock and ExprUnboxedClosure into one ExprClosure with an optional unboxed closure kind.
-