Update Fuchsia support for std::process.
- Adds support for try_wait.
- Miscellaneous updates to keep up with Magenta changes.
I'll begin `sys/fuchsia` soon, just been bogged down with my actual job lately (I'm not on the Fuchsia team).
exclusive range patterns
adds `..` patterns to the language under a feature gate (`exclusive_range_pattern`).
This allows turning
``` rust
match i {
0...9 => {},
10...19 => {},
20...29 => {},
_ => {}
}
```
into
``` rust
match i {
0..10 => {},
10..20 => {},
20..30 => {},
_ => {}
}
```
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.
cc #38531
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.
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
Add an option to the parser so cfg'ed out modules can still be parsed
r? @jseyfried
cc @dtolnay, @erickt it would be great if we could get this picked up into Syntex asap - it fixes a pretty nasty bug in Rustfmt.
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`.
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.
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.
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 ;-)
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.
Part of issue #39059 .
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.
libstd: replace all `try!` with `?` in documentation examples
See #38644.
For the record, I used the following Perl one-liner and then manually fixed a couple of things it got wrong:
$ perl -p -i -e 's#(///.*)try!\((.*)\)#$1$2?#' src/libstd/**/*.rs
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
```
failures:
---- [run-make] run-make/rustc-macro-dep-files stdout ----
error: make failed
status: exit code: 2
command: "make"
stdout:
------------------------------------------
DYLD_LIBRARY_PATH="/Users/lclark/Repos/rust/x86_64-apple-darwin/test/run-make/rustc-macro-dep-files.stage1-x86_64-apple-darwin:/Users/lclark/Repos/rust/x86_64-apple-darwin/stage1/lib:" '/Users/lclark/Repos/rust/x86_64-apple-darwin/stage1/bin/rustc' --out-dir /Users/lclark/Repos/rust/x86_64-apple-darwin/test/run-make/rustc-macro-dep-files.stage1-x86_64-apple-darwin -L /Users/lclark/Repos/rust/x86_64-apple-darwin/test/run-make/rustc-macro-dep-files.stage1-x86_64-apple-darwin foo.rs
DYLD_LIBRARY_PATH="/Users/lclark/Repos/rust/x86_64-apple-darwin/test/run-make/rustc-macro-dep-files.stage1-x86_64-apple-darwin:/Users/lclark/Repos/rust/x86_64-apple-darwin/stage1/lib:" '/Users/lclark/Repos/rust/x86_64-apple-darwin/stage1/bin/rustc' --out-dir /Users/lclark/Repos/rust/x86_64-apple-darwin/test/run-make/rustc-macro-dep-files.stage1-x86_64-apple-darwin -L /Users/lclark/Repos/rust/x86_64-apple-darwin/test/run-make/rustc-macro-dep-files.stage1-x86_64-apple-darwin bar.rs --emit dep-info
------------------------------------------
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.
failures:
[run-make] run-make/rustc-macro-dep-files
test result: FAILED. 136 passed; 1 failed; 0 ignored; 0 measured
thread 'main' panicked at 'Some tests failed', /Users/lclark/Repos/rust/src/tools/compiletest/src/main.rs:302
make: *** [tmp/check-stage1-T-x86_64-apple-darwin-H-x86_64-apple-darwin-rmake.ok] Error 101
```
r? @GuillaumeGomez
