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).
* 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.
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.
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
```
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
