- 25 3月, 2015 40 次提交
-
-
由 bors 提交于
Makes Vec::push considerably smaller: 25 instructions, rather than 42, on x86_64.
-
由 bors 提交于
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
-
由 bors 提交于
The compiler will now issue a warning for crates that have syntax of the form `extern crate "foo" as bar`, but it will still continue to accept this syntax. Additionally, the string `foo-bar` will match the crate name `foo_bar` to assist in the transition period as well. This patch will land hopefully in tandem with a Cargo patch that will start translating all crate names to have underscores instead of hyphens. cc #23533
-
由 Simonas Kazlauskas 提交于
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
Reject specialized Drop impls. See Issue #8142 for discussion. This makes it illegal for a Drop impl to be more specialized than the original item. So for example, all of the following are now rejected (when they would have been blindly accepted before): ```rust struct S<A> { ... }; impl Drop for S<i8> { ... } // error: specialized to concrete type struct T<'a> { ... }; impl Drop for T<'static> { ... } // error: specialized to concrete region struct U<A> { ... }; impl<A:Clone> Drop for U<A> { ... } // error: added extra type requirement struct V<'a,'b>; impl<'a,'b:a> Drop for V<'a,'b> { ... } // error: added extra region requirement ``` Due to examples like the above, this is a [breaking-change]. (The fix is to either remove the specialization from the `Drop` impl, or to transcribe the requirements into the struct/enum definition; examples of both are shown in the PR's fixed to `libstd`.) ---- This is likely to be the last thing blocking the removal of the `#[unsafe_destructor]` attribute. Fix #8142 Fix #23584
-
由 Alex Crichton 提交于
The compiler will now issue a warning for crates that have syntax of the form `extern crate "foo" as bar`, but it will still continue to accept this syntax. Additionally, the string `foo-bar` will match the crate name `foo_bar` to assist in the transition period as well. This patch will land hopefully in tandem with a Cargo patch that will start translating all crate names to have underscores instead of hyphens. cc #23533
-
由 Alex Crichton 提交于
The compiler will now issue a warning for crates that have syntax of the form `extern crate "foo" as bar`, but it will still continue to accept this syntax. Additionally, the string `foo-bar` will match the crate name `foo_bar` to assist in the transition period as well. This patch will land hopefully in tandem with a Cargo patch that will start translating all crate names to have underscores instead of hyphens. cc #23533
-
由 Alex Crichton 提交于
This commit alters the behavior of the `Read::read_to_end()` method to zero all memory instead of passing an uninitialized buffer to `read`. This change is motivated by the [discussion on the internals forum][discuss] where the conclusion has been that the standard library will not expose uninitialized memory. [discuss]: http://internals.rust-lang.org/t/uninitialized-memory/1652 Closes #20314
-
由 Alex Crichton 提交于
I assume since both shifts say the same thing, I should fix both of them, but then I realized I don't strictly know about left shift. Fixes #23421 r? @pnkfelix
-
由 Alex Crichton 提交于
For other permissions beside USR permissions, we need these constants. fixes #23658
-
由 Alex Crichton 提交于
This is pretty basic, but it's nice to have something. r? @alexcrichton
-
由 Alex Crichton 提交于
See notes on the first commit Closes #18601 r? @nikomatsakis cc @EddyB
-
由 Alex Crichton 提交于
Found a small typo on the Rust book "ownership" page. Best, Liam r? @steveklabnik
-
由 Alex Crichton 提交于
There have been some recent panics on the bots and this commit is an attempt to appease them. Previously it was considered invalid to run `rt::at_exit` after the handlers had already started running. Due to the multithreaded nature of applications, however, it is not always possible to guarantee this. For example [this program][ex] will show off the abort. [ex]: https://gist.github.com/alexcrichton/56300b87af6fa554e52d The semantics of the `rt::at_exit` function have been modified as such: * It is now legal to call `rt::at_exit` at any time. The return value now indicates whether the closure was successfully registered or not. Callers must now decide what to do with this information. * The `rt::at_exit` handlers will now be run for a fixed number of iterations. Common cases (such as the example shown) may end up registering a new handler while others are running perhaps once or twice, so this common condition is covered by re-running the handlers a fixed number of times, after which new registrations are forbidden. Some usage of `rt::at_exit` was updated to handle these new semantics, but deprecated or unstable libraries calling `rt::at_exit` were not updated.
-
由 Alex Crichton 提交于
-
由 Alex Crichton 提交于
The primary motivation here is to sidestep #19032 -- for a time, I thought that we should improve coherence or otherwise extend the language, but I now think that any such changes will require more time to bake. In the meantime, inheritance amongst the fn traits is both logically correct *and* a simple solution to that obstacle. This change introduces inheritance and modifies the compiler so that it can properly generate impls for closures and fns. Things enabled by this PR (but not included in this PR): 1. An impl of `FnMut` for `&mut F` where `F : FnMut` (https://github.com/rust-lang/rust/issues/23015). 2. A better version of `Thunk` I've been calling `FnBox`. I did not include either of these in the PR because: 1. Adding the impls in 1 currently induces a coherence conflict with the pattern trait. This is interesting and merits some discussion. 2. `FnBox` deserves to be a PR of its own. The main downside to this design is (a) the need to write impls by hand; (b) the possibility of implementing `FnMut` with different semantics from `Fn`, etc. Point (a) is minor -- in particular, it does not affect normal closure usage -- and could be addressed in the future in many ways (better defaults; convenient macros; specialization; etc). Point (b) is unfortunate but "just a bug" from my POV, and certainly not unique to these traits (c.f. Copy/Clone, PartialEq/Eq, etc). (Until we lift the feature-gate on implementing the Fn traits, in any case, there is room to correct both of these if we find a nice way.) Note that I believe this change is reversible in the future if we decide on another course of action, due to the feature gate on implementing the `Fn` traits, though I do not (currently) think we should reverse it. Fixes #18835. r? @nrc
-
由 Nick Cameron 提交于
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
See Issue 8142 for discussion. This makes it illegal for a Drop impl to be more specialized than the original item. So for example, all of the following are now rejected (when they would have been blindly accepted before): ```rust struct S<A> { ... }; impl Drop for S<i8> { ... } // error: specialized to concrete type struct T<'a> { ... }; impl Drop for T<'static> { ... } // error: specialized to concrete region struct U<A> { ... }; impl<A:Clone> Drop for U<A> { ... } // error: added extra type requirement struct V<'a,'b>; impl<'a,'b:a> Drop for V<'a,'b> { ... } // error: added extra region requirement ``` Due to examples like the above, this is a [breaking-change]. (The fix is to either remove the specialization from the `Drop` impl, or to transcribe the requirements into the struct/enum definition; examples of both are shown in the PR's fixed to `libstd`.) ---- This is likely to be the last thing blocking the removal of the `#[unsafe_destructor]` attribute. Includes two new error codes for the new dropck check. Update run-pass tests to accommodate new dropck pass. Update tests and docs to reflect new destructor restriction. ---- Implementation notes: We identify Drop impl specialization by not being as parametric as the struct/enum definition via unification. More specifically: 1. Attempt unification of a skolemized instance of the struct/enum with an instance of the Drop impl's type expression where all of the impl's generics (i.e. the free variables of the type expression) have been replaced with unification variables. 2. If unification fails, then reject Drop impl as specialized. 3. If unification succeeds, check if any of the skolemized variables "leaked" into the constraint set for the inference context; if so, then reject Drop impl as specialized. 4. Otherwise, unification succeeded without leaking skolemized variables: accept the Drop impl. We identify whether a Drop impl is injecting new predicates by simply looking whether the predicate, after an appropriate substitution, appears on the struct/enum definition.
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
This was necessary to avoid specialized `Drop` impls for the two structs.
-
由 Felix S. Klock II 提交于
one of the helper method impls.
-
由 Corey Richardson 提交于
Makes Vec::push considerably smaller: 25 instructions, rather than 42, on x86_64.
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
This permits all coercions to be performed in casts, but adds lints to warn in those cases. Part of this patch moves cast checking to a later stage of type checking. We acquire obligations to check casts as part of type checking where we previously checked them. Once we have type checked a function or module, then we check any cast obligations which have been acquired. That means we have more type information available to check casts (this was crucial to making coercions work properly in place of some casts), but it means that casts cannot feed input into type inference. [breaking change] * Adds two new lints for trivial casts and trivial numeric casts, these are warn by default, but can cause errors if you build with warnings as errors. Previously, trivial numeric casts and casts to trait objects were allowed. * The unused casts lint has gone. * Interactions between casting and type inference have changed in subtle ways. Two ways this might manifest are: - You may need to 'direct' casts more with extra type information, for example, in some cases where `foo as _ as T` succeeded, you may now need to specify the type for `_` - Casts do not influence inference of integer types. E.g., the following used to type check: ``` let x = 42; let y = &x as *const u32; ``` Because the cast would inform inference that `x` must have type `u32`. This no longer applies and the compiler will fallback to `i32` for `x` and thus there will be a type error in the cast. The solution is to add more type information: ``` let x: u32 = 42; let y = &x as *const u32; ```
-
由 Steve Klabnik 提交于
-