- 02 1月, 2015 5 次提交
-
-
由 Niko Matsakis 提交于
various bugs in `trait_id_of_impl`. The end result was that looking up the "trait_id_of_impl" with a trait's def-id yielded the same trait again, even though it ought to have yielded None.
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
rules and cannot be updated until the libraries are synced, nor can they opt in to the old semantics.
-
由 Niko Matsakis 提交于
Fix orphan checking (cc #19470). (This is not a complete fix of #19470 because of the backwards compatibility feature gate.) This is a [breaking-change]. The new rules require that, for an impl of a trait defined in some other crate, two conditions must hold: 1. Some type must be local. 2. Every type parameter must appear "under" some local type. Here are some examples that are legal: ```rust struct MyStruct<T> { ... } // Here `T` appears "under' `MyStruct`. impl<T> Clone for MyStruct<T> { } // Here `T` appears "under' `MyStruct` as well. Note that it also appears // elsewhere. impl<T> Iterator<T> for MyStruct<T> { } ``` Here is an illegal example: ```rust // Here `U` does not appear "under" `MyStruct` or any other local type. // We call `U` "uncovered". impl<T,U> Iterator<U> for MyStruct<T> { } ``` There are a couple of ways to rewrite this last example so that it is legal: 1. In some cases, the uncovered type parameter (here, `U`) should be converted into an associated type. This is however a non-local change that requires access to the original trait. Also, associated types are not fully baked. 2. Add `U` as a type parameter of `MyStruct`: ```rust struct MyStruct<T,U> { ... } impl<T,U> Iterator<U> for MyStruct<T,U> { } ``` 3. Create a newtype wrapper for `U` ```rust impl<T,U> Iterator<Wrapper<U>> for MyStruct<T,U> { } ``` Because associated types are not fully baked, which in the case of the `Hash` trait makes adhering to this rule impossible, you can temporarily disable this rule in your crate by using `#![feature(old_orphan_check)]`. Note that the `old_orphan_check` feature will be removed before 1.0 is released.
-
由 Niko Matsakis 提交于
-
- 01 1月, 2015 35 次提交
-
-
由 bors 提交于
Uses the same approach as https://github.com/rust-lang/rust/pull/17286 (and subsequent changes making it more correct), where the visitor will skip any pieces of the AST that are from "foreign code", where the spans don't line up, indicating that that piece of code is due to a macro expansion. If this breaks your code, read the error message to determine which feature gate you should add to your crate. Closes #18102 [breaking-change]
-
由 Corey Richardson 提交于
Uses the same approach as https://github.com/rust-lang/rust/pull/17286 (and subsequent changes making it more correct), where the visitor will skip any pieces of the AST that are from "foreign code", where the spans don't line up, indicating that that piece of code is due to a macro expansion. If this breaks your code, read the error message to determine which feature gate you should add to your crate, and bask in the knowledge that your code won't mysteriously break should you try to use the 1.0 release. Closes #18102 [breaking-change]
-
由 bors 提交于
r? @huonw or @alexcrichton Apparently, we have previously rejected an RFC like this. However, since then we removed `{:?}` and so without this debugging gets really difficult as soon as there is a RefCell anywhere, so I believe there is more benefit to adding these impls than there was before. By using "try_borrow" we can avoid panicing in `Show` (I think). @ huon in response to a comment in #19254: I noticed that `drop()` checks for the ptr being null, so I checked here too. Now I am checking for both, if you're confident I can change to only checking `strong()`.
-
由 Nick Cameron 提交于
-
由 Nick Cameron 提交于
-
由 bors 提交于
The the last argument of the `ItemDecorator::expand` method has changed to `Box<FnMut>`. Syntax extensions will break. [breaking-change] --- This PR removes pretty much all the remaining uses of boxed closures from the libraries. There are still boxed closures under the `test` directory, but I think those should be removed or replaced with unboxed closures at the same time we remove boxed closures from the language. In a few places I had to do some contortions (see the first commit for an example) to work around issue #19596. I have marked those workarounds with FIXMEs. In the future when `&mut F where F: FnMut` implements the `FnMut` trait, we should be able to remove those workarounds. I've take care to avoid placing the workaround functions in the public API. Since `let f = || {}` always gets type checked as a boxed closure, I have explictly annotated those closures (with e.g. `|&:| {}`) to force the compiler to type check them as unboxed closures. Instead of removing the type aliases (like `GetCrateDataCb`), I could have replaced them with newtypes. But this seemed like overcomplicating things for little to no gain. I think we should be able to remove the boxed closures from the languge after this PR lands. (I'm being optimistic here) r? @alexcrichton or @aturon cc @nikomatsakis
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 bors 提交于
These mostly derive from problems that @japaric encountered. r? @pcwalton
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 bors 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
due to this but we were not able to isolate a smaller test case.
-