- 28 1月, 2017 9 次提交
-
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 bors 提交于
rustc: Remove all "consider using an explicit lifetime parameter" suggestions These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing, _the compiler itself_ appears to not understand borrowing. It does not inspire confidence. r? @nikomatsakis
-
由 bors 提交于
travis: Turn off core dumps on OSX I've seen these take up quite a bit of log space and I have the sneaking suspicion that they're just making our test suite take longer (sometimes timing out on 32-bit OSX now). In any case the backtraces haven't proven too useful, unfortunately.
-
- 27 1月, 2017 11 次提交
-
-
由 bors 提交于
Stabilize Self and associated types in struct expressions and patterns Rebase of https://github.com/rust-lang/rust/pull/37734 Closes https://github.com/rust-lang/rust/issues/37544 r? @nikomatsakis
-
由 bors 提交于
Hide a few more standard library symbols These commits touch up some of the symbol visibility rules for some crates related to the standard library, notably: * Symbols that are `pub extern` and `#[no_mangle]` which are internal-to-rust ABI things are no longer at the `C` export level, but the `Rust` export level. This includes allocators, panic runtimes, and compiler builtins. * The libbacktrace library is now compiled with `-fvisibility=hidden` to ensure that we don't export those symbols.
-
由 Alex Crichton 提交于
We don't want these symbols exported from the standard library, this is just an internal implementation detail of the standard library currently. Closes #34984
-
由 Alex Crichton 提交于
This hides symbols from various unstable and implementation-detail crates of the standard library. Although typically transitive exported `pub extern` functions are exported from cdylibs, these crates aren't necessary as they're all implementation details. Closes #34493
-
由 bors 提交于
incr.comp.: Make cross-crate tracking for incr. comp. opt-in. The current implementation of cross-crate dependency tracking can cause quite long compile times and high memory usage for some crates (see #39208 for example). This PR therefore makes that part of dependency tracking optional. Incremental compilation still works, it will only have very coarse dep-tracking for upstream crates. r? @nikomatsakis
-
由 bors 提交于
Point to immutable arg/fields when trying to use as &mut Present the following output when trying to access an immutable borrow's field as mutable: ``` error[E0389]: cannot borrow data mutably in a `&` reference --> $DIR/issue-38147-1.rs:27:9 | 26 | fn f(&self) { | ----- use `&mut self` here to make mutable 27 | f.s.push('x'); | ^^^ assignment into an immutable reference ``` And the following when trying to access an immutable struct field as mutable: ``` error: cannot borrow immutable borrowed content `*self.s` as mutable --> $DIR/issue-38147-3.rs:17:9 | 12 | s: &'a String | ------------- use `&'a mut String` here to make mutable ...| 16 | fn f(&self) { | ----- use `&mut self` here to make mutable 17 | self.s.push('x'); | ^^^^^^ cannot borrow as mutable ``` Fixes #38147.
-
由 bors 提交于
Bounds parsing refactoring 2 See https://github.com/rust-lang/rust/pull/37511 for previous discussion. cc @matklad Relaxed parsing rules: - zero bounds after `:` are allowed in all contexts. - zero predicates are allowed after `where`. - trailing separator `,` is allowed after predicates in `where` clauses not followed by `{`. Other parsing rules: - trailing separator `+` is still allowed in all bound lists. Code is also cleaned up and tests added. I haven't touched parsing of trait object types yet, I'll do it later.
-
由 Brian Anderson 提交于
These give so many incorrect suggestions that having them is detrimental to the user experience. The compiler should not be suggesting changes to the code that are wrong - it is infuriating: not only is the compiler telling you that _you don't understand_ borrowing, _the compiler itself_ appears to not understand borrowing. It does not inspire confidence.
-
由 Esteban Küber 提交于
Point to immutable borrow arguments and fields when trying to use them as mutable borrows. Add label to primary span on "cannot borrow as mutable" errors. Present the following output when trying to access an immutable borrow's field as mutable: ``` error[E0389]: cannot borrow data mutably in a `&` reference --> $DIR/issue-38147-1.rs:27:9 | 26 | fn f(&self) { | ----- use `&mut self` here to make mutable 27 | f.s.push('x'); | ^^^ assignment into an immutable reference ``` And the following when trying to access an immutable struct field as mutable: ``` error: cannot borrow immutable borrowed content `*self.s` as mutable --> $DIR/issue-38147-3.rs:17:9 | 12 | s: &'a String | ------------- use `&'a mut String` here to make mutable ...| 16 | fn f(&self) { | ----- use `&mut self` here to make mutable 17 | self.s.push('x'); | ^^^^^^ cannot borrow as mutable ```
-
由 bors 提交于
End temporary lifetimes being extended by `let X: &_` hints cc #39283 r? @nikomatsakis
-
由 Alex Crichton 提交于
I've seen these take up quite a bit of log space and I have the sneaking suspicion that they're just making our test suite take longer (sometimes timing out on 32-bit OSX now). In any case the backtraces haven't proven too useful, unfortunately.
-
- 26 1月, 2017 20 次提交
-
-
由 bors 提交于
Rename tcx.map to the far more descriptive tcx.hir. Also a bit more renaming because `ast_map` and `'ast` were still used with HIR. Main motivation is to "free up" `tcx.map`, or rather, `tcx.maps`, to consolidate `ty::maps` there. r? @nikomatsakis
-
由 Vadim Petrochenkov 提交于
-
由 bors 提交于
Add a distinct error code and description for "main function has wron… …g type"
-
由 Eduard-Mihai Burtescu 提交于
-
由 Eduard-Mihai Burtescu 提交于
-
由 Guillaume Gomez 提交于
-
由 Guillaume Gomez 提交于
-
由 bors 提交于
Remove Reflect PR for removing the `Reflect` trait. Opened so that a crater run can be done for testing the impact: https://github.com/rust-lang/rust/issues/27749#issuecomment-272665163 Fixes #27749
-
由 bors 提交于
process trait/impl items directly from the visitor callback The current setup processes impl/trait items while visiting the impl/trait. This means we basically have this setup: <Lots> -> TypeckItemBody(Impl) -> Tables(ImplItem{0,1,2,3}) But this was largely an artifact of the older code. By moving the processing of items into method dedicated for their use, we produce this setup: <Little> -> TypeckItemBody(ImplItem0) -> Tables(ImplItem0) ... <Little> -> TypeckItemBody(ImplItem3) -> Tables(ImplItem3) r? @michaelwoerister Also, we might consider removing the `TypeckItemBody` node altogether and just using `Tables` as the task. `Tables` is its primary output, I imagine? That would reduce size of dep-graph somewhat. cc @EddyB -- perhaps this pattern applies elsewhere?
-
由 bors 提交于
Fix wording around sort guarantees Fixes #38524 /cc @rust-lang/libs @stjepang
-
由 bors 提交于
Partially implement RFC 1647 (`Self` in impl headers) The name resolution part is easy, but the typeck part contains an unexpected problem. It turns out that `Self` type *depends* on bounds and `where` clauses, so we need to convert them first to determine what the `Self` type is! If bounds/`where` clauses can refer to `Self` then we have a cyclic dependency. This is required to support impls like this: ``` // Found in libcollections impl<I: IntoIterator> SpecExtend<I> for LinkedList<I::Item> { .... } ^^^^^ associated type `Item` is found using information from bounds ``` I'm not yet sure how to resolve this issue. One possible solution (that feels hacky) is to make two passes over generics - first collect predicates ignoring everything involving `Self`, then determine `Self`, then collect predicates again without ignoring anything. (Some kind of lazy on-demand checking or something looks like a proper solution.) This patch in its current state doesn't solve the problem with `Self` in bounds, so the only observable things it does is improving error messages and supporting `impl Trait<Self> for Type {}`. There's also a question about feature gating. It's non-trivial to *detect* "newly resolved" `Self`s to feature gate them, but it's simple to *enable* the new resolution behavior when the feature gate is already specified. Alternatively this can be considered a bug fix and merged without a feature gate. cc https://github.com/rust-lang/rust/issues/38864 r? @nikomatsakis cc @EddyB Whitespace ignoring diff https://github.com/rust-lang/rust/pull/38920/files?w=1
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
-
由 Niko Matsakis 提交于
The current setup processes impl/trait items while visiting the impl/trait. This means we basically have this setup: <Lots> -> TypeckItemBody(Impl) -> Tables(ImplItem{0,1,2,3}) But this was largely an artifact of the older code. By moving the processing of items into method dedicated for their use, we produce this setup: <Little> -> TypeckItemBody(ImplItem0) -> Tables(ImplItem0) ... <Little> -> TypeckItemBody(ImplItem3) -> Tables(ImplItem3)
-
由 bors 提交于
Add std::process::Command::envs() `Command::envs()` adds a vector of key-value pairs to the child process environment all at once. Suggested in #38526. This is not fully baked and frankly I'm not sure it even _works_, but I need some help finishing it up, and this is the simplest way to show you what I've got. The problems I know exist and don't know how to solve, from most to least important, are: * [ ] I don't know if the type signature of the new function is correct. * [x] The new test might not be getting run. I didn't see it go by in the output of `x.py test src/libstd --stage 1`. * [x] The tidy check says ``process.rs:402: different `since` than before`` which I don't know what it means. r? @brson
-
由 Stjepan Glavina 提交于
-
由 Stjepan Glavina 提交于
-