- 03 9月, 2016 25 次提交
-
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
Parse union items and add a feature for them
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 Vadim Petrochenkov 提交于
-
由 bors 提交于
rustc: Implement custom derive (macros 1.1) This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate, both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC, such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation, however, not the public interface. This commit also ended up touching a lot of code related to `#[derive]`, making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default, they have to opt in on a granular level. * The `derive(Copy,Clone)` optimization is now done through another "obscure attribute" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq,Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io!
-
由 bors 提交于
Introduce max_by/min_by on iterators See https://github.com/rust-lang/rfcs/issues/1722 for reference. It seems that there is `min`, `max` (simple computation of min/max), `min_by_key`, `max_by_key` (min/max by comparing mapped values) but no `min_by` and `max_by` (min/max according to comparison function). However, e.g. on vectors or slices there is `sort`, `sort_by_key` and `sort_by`.
-
由 bors 提交于
Rollup of 12 pull requests - Successful merges: #35754, #35793, #36099, #36160, #36171, #36178, #36180, #36190, #36198, #36205, #36210, #36223 - Failed merges:
-
由 Jonathan Turner 提交于
Update compiler error E0558 to use new error format Fixes #36196 part of #35233 r? @jonathandturner
-
由 Jonathan Turner 提交于
Fixed E0529's label and unit test Fixes #36195 part of #35233. This is ready for review, but will likely fail Travis due to #36138. I changed the wording of the label, so feedback on that would be appreciated. r? @jonathandturner
-
由 Jonathan Turner 提交于
Fixed E0528 label and unit test Fixes #36194 part of #35233. r? @jonathandturner
-
由 Jonathan Turner 提交于
test: Add a min-llvm-version directive We've got tests which require a particular version of LLVM to run as they're testing bug fixes. Our build system, however, supports multiple LLVM versions, so we can't run these tests on all LLVM versions. This adds a new `min-llvm-version` directive for tests so they can opt out of being run on older versions of LLVM. This then namely applies that logic to the `issue-36023.rs` test case and... Closes #36138
-
由 Jonathan Turner 提交于
configure: check if any of the arguments contain --help Currently it checks only the first argument. Fixes #31216
-
由 Jonathan Turner 提交于
Transition Travis CI to use rustbuild.
-
由 Jonathan Turner 提交于
Special case a few colors for Windows As brought up on [this thread](https://github.com/rust-lang/rust/issues/33240#issuecomment-243310067) the colors used in error messages on Windows can be difficult to read because of the lack of bold. This PR makes a few changes to improve readability, namely: * Rather than using BRIGHT_BLUE, on Windows we now use BRIGHT_CYAN, which is easier to read on black when you do not have bold * We used BRIGHT_YELLOW rather than YELLOW, for the same reason * Titles will be BRIGHT_WHITE now, to give the illusion of being bold Some examples: ![warning](https://cloud.githubusercontent.com/assets/547158/18148466/9aa9bbe2-6f8e-11e6-927f-d0eec53cac32.PNG) ![error](https://cloud.githubusercontent.com/assets/547158/18148488/ba9fb186-6f8e-11e6-8d8e-e93d569f61de.PNG) r? @nikomatsakis cc @retep998
-
由 Jonathan Turner 提交于
Update lifetime errors to specifically note temporaries This PR updates the error message we give in the case of a temporary value not living long enough. Before: <img width="497" alt="screen shot 2016-08-31 at 10 02 47 am" src="https://cloud.githubusercontent.com/assets/547158/18138551/27a06794-6f62-11e6-9ee2-bdf8bed75ca7.png"> Now: <img width="488" alt="screen shot 2016-08-31 at 10 03 01 am" src="https://cloud.githubusercontent.com/assets/547158/18138557/2e5cf322-6f62-11e6-9047-4a78abf3d78c.png"> Specifically, it makes the following changes: * Detects if a temporary is being used. If so, it changes the labels to mention that a temporary value specifically is in question * Simplifies wording of the existing labels to focus on lifetimes rather than values being valid * Changes the help to a note, since the help+span wasn't as helpful (and sometimes more confusing) than just a note. r? @nikomatsakis
-
由 Jonathan Turner 提交于
Normalize the function signature of closures Previously we didn't normalize the function signatures used for closures. This didn't cause a problem in most cases, but caused an ICE in during MIR type checking. Fixes #36139 r? @EddyB
-
由 Jonathan Turner 提交于
Document try!'s error conversion behaviour try!'s documentation currently doesn't document the error conversion behaviour of the macro. This patch extends the documentation. Open questions: * is it worthwhile to have seperate examples with and without wrapping behaviour? It's not immediately obvious that From<T> for T is always defined. Though this is necessary for the macro to work in any case, is this the place to expect that knowledge.
-
由 Jonathan Turner 提交于
demonstrate `RHS != Self` use cases for `Add` and `Sub`
-
由 Jonathan Turner 提交于
Add `must_use` to the Reference I'm a bit uncertain about the exact phrasing, but having it mentioned at all is probably better than before.
-
由 Abhishek Kumar 提交于
Fixes #36196 part of #35233
-
由 Alex Crichton 提交于
This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate, both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC, such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation, however, not the public interface. This commit also ended up touching a lot of code related to `#[derive]`, making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default, they have to opt in on a granular level. * The `derive(Copy,Clone)` optimization is now done through another "obscure attribute" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq,Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]
-
由 Corey Farwell 提交于
-
由 bors 提交于
Address FIXME in libcollectionstest/btree/set.rs
-
- 02 9月, 2016 15 次提交
-
-
由 bors 提交于
add mips64-gnu and mips64el-gnu targets With this commit one can build no_core (and probably no_std as well) Rust programs for these targets. It's not yet possible to cross compile std for these targets because rust-lang/libc doesn't know about the mips64 architecture. These targets have been tested by cross compiling the "smallest hello" program (see code below) and then running it under QEMU. ``` rust extern { fn puts(_: *const u8); } fn start(_: isize, _: *const *const u8) -> isize { unsafe { let msg = b"Hello, world!\0"; puts(msg as *const _ as *const u8); } 0 } trait Copy {} trait Sized {} ``` cc #36015 r? @alexcrichton cc @brson The cabi stuff is likely wrong. I just copied cabi_mips source and changed some `4`s to `8`s and `32`s to `64`s. It was enough to get libc's `puts` to work but I'd like someone familiar with this module to check it.
-
由 bors 提交于
implementing RFC 1623. This fixes #35897. This is a work in progress. In particular, I want to add more tests, especially the compile-fail test is very bare-bones.
-
由 Eugene R Gonzalez 提交于
-
由 bors 提交于
Implement RFC 1560 behind `#![feature(item_like_imports)]` This implements https://github.com/rust-lang/rfcs/pull/1560 (cc #35120) behind the `item_like_imports` feature gate. The [RFC text](https://github.com/rust-lang/rfcs/blob/master/text/1560-name-resolution.md#changes-to-name-resolution-rules) describes the changes to name resolution enabled by `#![feature(item_like_imports)` in detail. To summarize, - Items and named imports shadow glob imports. - Multiple globs can import the same name if the name is unused or the imports are shadowed. - Multiple globs can import the same name if the imports are of the same item (following re-exports). - The visibility of such a name is the maximum visibility of the imports. - Equivalently, adding a glob import will never reduce the visibility of a name, nor will removing one increase it. - Non-prelude private imports can be used wherever we currently allow private items to be used. - Prelude-imported names are unaffected, i.e. they continue to be usable only in lexical scopes. - Globs import all visible names, not just public names. - Equivalently, glob importing from an ancestor module imports all of the ancestor's names, and glob importing from other modules is unchanged. r? @nrc
-
由 Jeffrey Seyfried 提交于
-
由 Alex Crichton 提交于
We've got tests which require a particular version of LLVM to run as they're testing bug fixes. Our build system, however, supports multiple LLVM versions, so we can't run these tests on all LLVM versions. This adds a new `min-llvm-version` directive for tests so they can opt out of being run on older versions of LLVM. This then namely applies that logic to the `issue-36023.rs` test case and... Closes #36138
-
由 Eugene R Gonzalez 提交于
-
由 Jeffrey Seyfried 提交于
-
由 Jeffrey Seyfried 提交于
-
由 Jeffrey Seyfried 提交于
-
由 Jeffrey Seyfried 提交于
-
由 Jeffrey Seyfried 提交于
-
由 Jeffrey Seyfried 提交于
to reexport some (but not all) names with less visibility.
-
由 Jeffrey Seyfried 提交于
to reexport some (but not all) namespaces with less visibility.
-
由 Jeffrey Seyfried 提交于
-