bors [Wed, 25 Jan 2017 23:08:56 +0000 (23:08 +0000)]
Auto merge of #38920 - petrochenkov:selfimpl, r=eddyb
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
bors [Wed, 25 Jan 2017 20:24:02 +0000 (20:24 +0000)]
Auto merge of #38856 - zackw:process-envs, r=aturon
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.
bors [Tue, 24 Jan 2017 23:34:35 +0000 (23:34 +0000)]
Auto merge of #39245 - alexcrichton:enable-platform, r=brson
rustbuild: Start building --enable-extended
This commit adds a new flag to the configure script,
`--enable-extended`, which is intended for specifying a desire to
compile the full suite of Rust tools such as Cargo, the RLS, etc. This
is also an indication that the build system should create combined
installers such as the pkg/exe/msi artifacts.
Currently the `--enable-extended` flag just indicates that combined
installers should be built, and Cargo is itself not compiled just yet
but rather only downloaded from its location. The intention here is to
quickly get to feature parity with the current release process and then
we can start improving it afterwards.
All new files in this PR inside `src/etc/installer` are copied from the
rust-packaging repository.
Alex Crichton [Sat, 21 Jan 2017 01:03:06 +0000 (17:03 -0800)]
rustbuild: Start building --enable-extended
This commit adds a new flag to the configure script,
`--enable-extended`, which is intended for specifying a desire to
compile the full suite of Rust tools such as Cargo, the RLS, etc. This
is also an indication that the build system should create combined
installers such as the pkg/exe/msi artifacts.
Currently the `--enable-extended` flag just indicates that combined
installers should be built, and Cargo is itself not compiled just yet
but rather only downloaded from its location. The intention here is to
quickly get to feature parity with the current release process and then
we can start improving it afterwards.
All new files in this PR inside `src/etc/installer` are copied from the
rust-packaging repository.
bors [Tue, 24 Jan 2017 11:51:34 +0000 (11:51 +0000)]
Auto merge of #39214 - estebank:fix-labels-without-msg, r=nikomatsakis
Fix multiple labels when some don't have message
The diagnostic emitter now accounts for labels with no text message, presenting the underline on its own, without drawing the line for the non existing message below it. Go from
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ----^^^^^^^----
| | |
| | `b` is a good letter
|
```
to
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ----^^^^^^^----
| |
| `b` is a good letter
```
from
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ^^^^-------^^^^
| | |
| |
| `a` is a good letter
```
to
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ^^^^-------^^^^ `a` is a good letter
```
and from
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ^^^^-------^^^^
| | |
| |
|
```
to
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ^^^^-------^^^^
```
r? @nikomatsakis
cc @jonathandturner, @GuillaumeGomez, @nrc
bors [Tue, 24 Jan 2017 01:17:09 +0000 (01:17 +0000)]
Auto merge of #39048 - lambda:impl-tosocketaddrs-for-string, r=alexcrichton
impl ToSocketAddrs for String
`ToSocketAddrs` is implemented for a number of different types,
including `(IpAddr, u16)`, `&str`, and various others, for the
convenience of being able to run things like
`TcpListener::bind("10.11.12.13:1415")`. However, because this is a
generic parameter with a trait bound, if you have a `String` you cannot
pass it in, either directly as `TcpListener::bind(string)`, or the
`TcpListener::bind(&string)` as you might expect due to deref coercion;
you have to use `TcpListener::bind(&*string)`, which is noisy and hard
to discover (though #39029 suggests better error messages to make it
more discoverable).
Rather than making people stumble over this, just implement
`ToSocketAddrs` for `String`.
Steve Klabnik [Mon, 23 Jan 2017 21:40:53 +0000 (16:40 -0500)]
Rollup merge of #39258 - jacwah:makefile-note, r=aturon
build: Mention rustbuild in Makefile.in comments
I think this patch will help newcomers like myself with the build system. I didn't understand that the make targets listed in the Makefile.in comments only worked with the old system, until it was pointed out to me in #39256.
Steve Klabnik [Mon, 23 Jan 2017 21:40:49 +0000 (16:40 -0500)]
Rollup merge of #39191 - cesarb:book/trait-objects-vtable-size-and-align, r=steveklabnik
book: size and align in trait object vtables are used
The book currently claims that the `size` and `align` fields in the
trait object vtable are not used, but this is false. These two fields
are used by the stable `mem::size_of_val` and `mem::align_of_val`
functions.
See the `ty::TyDynamic` case of the `glue::size_and_align_of_dst`
function in librustc_trans, which is used to implement both intrinsics
in the unsized case.
Steve Klabnik [Mon, 23 Jan 2017 21:40:46 +0000 (16:40 -0500)]
Rollup merge of #38794 - ConnyOnny:master, r=steveklabnik
book: match enum warning
Matching enums with named fields in the previous way yielded the "non_shorthand_field_patterns" warning.
The new code shows the shorthand syntax as well as field renaming, so it should be exhaustive ;-)
bors [Mon, 23 Jan 2017 00:36:00 +0000 (00:36 +0000)]
Auto merge of #39247 - est31:master, r=jseyfried
Remove proc_macro from the tidy whitelist again
PR #38842 has exposed that we were missing the src/test/compile-fail-fulldeps
directory in the search for feature gate tests. Because the detection didn't
work despite the effort to name the test appropriately and add a correct
"// gate-test-proc_macro" comment, proc_macro was added to the whitelist.
We fix this little weakness in the feature gate tidy check and add
the src/test/compile-fail-fulldeps directory to the checked directories.
est31 [Sun, 22 Jan 2017 22:05:51 +0000 (23:05 +0100)]
Remove proc_macro from the tidy whitelist again
PR #38842 has exposed that we were missing the src/test/compile-fail-fulldeps
directory in the search for feature gate tests. Because the detection didn't
work despite the effort to name the test appropriately and add a correct
"// gate-test-proc_macro" comment, proc_macro was added to the whitelist.
We fix this little weakness in the feature gate tidy check and add
the src/test/compile-fail-fulldeps directory to the checked directories.
bors [Sun, 22 Jan 2017 14:38:04 +0000 (14:38 +0000)]
Auto merge of #38108 - linclark:32777-E0328, r=GuillaumeGomez
Add error explanation for E0328.
This PR adds an explanation for an error in the list in #32777.
I haven't used this feature myself, so I was piecing it together from the docs. Please let me know if any changes in wording should be made.
One problem: When I followed the instructions in CONTRIBUTING.md, it said to run `make check-stage1` before posting the PR. This reported failures, but they seemed to be intermittent. I got different numbers of failures on each run. Here's the output for the last run
------------------------------------------
stderr:
------------------------------------------
dyld: lazy symbol binding failed: Symbol not found: __ZN4core3fmt5write17h2f7663117dd4fb40E
Referenced from: /Users/lclark/Repos/rust/x86_64-apple-darwin/test/run-make/rustc-macro-dep-files.stage1-x86_64-apple-darwin/libfoo.dylib
Expected in: /Users/lclark/Repos/rust/x86_64-apple-darwin/stage1/lib/libstd-fdb5dc8c.dylib
dyld: Symbol not found: __ZN4core3fmt5write17h2f7663117dd4fb40E
Referenced from: /Users/lclark/Repos/rust/x86_64-apple-darwin/test/run-make/rustc-macro-dep-files.stage1-x86_64-apple-darwin/libfoo.dylib
Expected in: /Users/lclark/Repos/rust/x86_64-apple-darwin/stage1/lib/libstd-fdb5dc8c.dylib
make[1]: *** [all] Trace/BPT trap: 5
------------------------------------------
thread '[run-make] run-make/rustc-macro-dep-files' panicked at 'explicit panic', /Users/lclark/Repos/rust/src/tools/compiletest/src/runtest.rs:2407
note: Run with `RUST_BACKTRACE=1` for a backtrace.
bors [Sat, 21 Jan 2017 22:07:14 +0000 (22:07 +0000)]
Auto merge of #39218 - xen0n:syntax-warts, r=alexcrichton
syntax: remove abi::Os and abi::Architecture
They're long dead since the switch to flexible targets, but was not removed like their consumers were. Interesting they even got maintained by various porters out there!
Technically [syntax-breaking] as they're public API, but since they're unused in the compiler, the potential breakage IMO should be minimal.
bors [Sat, 21 Jan 2017 16:51:22 +0000 (16:51 +0000)]
Auto merge of #39203 - ranma42:doc_metadata, r=BurntSushi
Document that `Metadata` can be obtained from `symlink_metadata`
When retrieving the information about a syslink (specifically, when invoking `Metadata::is_symlink`) you generally want the `syslink_metadata`. It would be natural to point at both options to retrieve a `Metadata` value, as they are both appropriate (for different use cases).
Zack Weinberg [Sat, 21 Jan 2017 16:01:11 +0000 (11:01 -0500)]
Generalize envs() and args() to iterators.
* Command::envs() now takes anything that is IntoIterator<Item=(K, V)>
where both K and V are AsRef<OsStr>.
* Since we're not 100% sure that's the right signature, envs() is
now marked unstable. (You can use envs() with HashMap<str, str> but
not Vec<(str, str)>, for instance.)
* Update the test to match.
* By analogy, args() now takes any IntoIterator<Item=S>, S: AsRef<OsStr>.
This should be uncontroversial.
bors [Sat, 21 Jan 2017 08:41:40 +0000 (08:41 +0000)]
Auto merge of #39206 - MJDSys:fix_rustbuild_libdir, r=alexcrichton
Fix rustbuild to work with --libdir.
Similar to the makefiles, pass CFG_LIBDIR_RELATIVE to cargo when building
rustc in stages > 0. This tells rustc to check the different directory.
I'm not sure how you want this handled in the toml system (my distribution, Gentoo, uses configure still). I have a feeling the system needs a rework anyways for rustbuild. If there is some discussion that needs to happen, could you merge this in the mean time? I'd be happy to help transition this to a better method.
Wang Xuerui [Sat, 21 Jan 2017 07:05:41 +0000 (15:05 +0800)]
syntax: remove abi::Os and abi::Architecture
They're long dead since the switch to flexible targets, but was not
removed like their consumers were. Interesting they even got maintained
by various porters out there!
Technically [syntax-breaking] as they're public API, but since they're
unused in the compiler, the potential breakage IMO should be minimal.
Esteban Küber [Sat, 21 Jan 2017 02:57:21 +0000 (18:57 -0800)]
Fix multiple labels when some don't have message
The diagnostic emitter now accounts for labels with no text message,
presenting the underline on its own, without drawing the line for the
non existing message below it. Go from
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ----^^^^^^^----
| | |
| | `b` is a good letter
|
```
to
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ----^^^^^^^----
| |
| `b` is a good letter
```
and from
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ^^^^-------^^^^
| | |
| |
| `a` is a good letter
```
to
```
error: foo
--> test.rs:3:6
|
3 | a { b { c } d }
| ^^^^-------^^^^ `a` is a good letter
```
bors [Sat, 21 Jan 2017 03:26:37 +0000 (03:26 +0000)]
Auto merge of #39086 - aidanhs:aphs-local-rebuild-no-jemalloc, r=alexcrichton
Make rustbuild force_alloc_system rather than relying on stage0
This 'fixes' jemalloc-less local rebuilds, where we tell cargo that we're actually stage1 (this only fixes the rustbuild path, since I wasn't enthusiastic to dive into the makefiles).
There should be one effect from this PR: `--enable-local-rebuild --disable-jemalloc` will successfully build a stage0 std (rather than erroring). Ideally I think it'd be nice to specify an allocator preference in Cargo.toml/cargo command line (used when an allocator must be picked i.e. dylibs, not rlibs), but since that's not possible we can make do with a force_alloc_system feature. Sadly this locks you into a single allocator in the build libstd, making any eventual implementation of #38575 not quite right in this edge case, but clearly not many people exercise the combination of these two flags.
This PR is also a substitute for #37975 I think. The crucial difference is that the feature name here is distinct from the jemalloc feature (reused in the previous PR) - we don't want someone to be forced into alloc_system just for disabling jemalloc!
Accepting parens in this position is a regression itself, introduced in Rust 1.6 by https://github.com/rust-lang/rust/pull/29870, so I hope to revert this in my next bounds refactoring patch (possibly with a warning, crater run, etc).
Alex Crichton [Thu, 19 Jan 2017 23:49:47 +0000 (15:49 -0800)]
Rollup merge of #39168 - estebank:multiline-candidate, r=petrochenkov
Use multiline Diagnostic for candidate in other module
```
error[E0574]: expected struct, variant or union type, found enum `Result`
--> $DIR/issue-16058.rs:19:9
|
19 | Result {
| ^^^^^^ not a struct, variant or union type
|
= help: possible better candidates are found in other modules, you can import them into scope:
`use std::fmt::Result;`
`use std::io::Result;`
`use std::thread::Result;`
projects / rust.git / log