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
Use fs::symlink_metadata in doc for is_symlink
fs::metadata() follows symlinks so is_symlink() will always return
false. Use symlink_metadata instead in the example in the
documentation.
See issue #39088.
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.
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).
linkchecker: Fix checking links which are just fragments
Also fix a typo which linkchecker should have caught.
It was broken by 31a8638e5e.
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.
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.
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!
Fixes#39054
r? @alexcrichton
