The "Rust Inside Other Languages" page includes a library example. The
reference specifies printing "done!" when the code finishes running, and
the language examples (Ruby, Python, JS) all do this in their code.
However, the Rust library example code *also* does this, so that the
examples as written would output "done!" twice.
This removes the "done!" from the Rust example code to clarify the docs.
This is part of #28572, but doesn't complete it. Amongst other things,
this patch:
* Increases consistency in the way feature flags are used with other
docs.
* Removes the ignores, which is nice: we actually had some syntax errors
in the examples 😭.
* Mentions #![no_core]
Realistically, this document used to be in the order of least to most:
nothing, then adding core. But with the changes in RFC 1184, this is
backwards: it now shows stuff that uses core from the beginning. In the
future, I'd like to revamp this to go from 'most to least', but I'd like
to see the discussion in https://github.com/rust-lang/rust/issues/27701
goes before I write more.
We don't completely cover documentation tests in the testing chapter,
since we cover them in the documentation chapter. So make sure people
know that.
Fixes#28082
The original blog post referred to examples by their file names, and now
that it's in guide form, there is no file name. So edit the text so that
it makes a bit more sense.
Fixes#28428
The links in the rustdoc for several places in fmt were trying to link to
the std::fmt module but actually linking to std, which was confusing.
While trying to figure out why I noticed that the documentation chapter of
the Rust book has examples that show this same bug (although it doesn't seem
widespread in practice).
r? @steveklabnik
We don't completely cover documentation tests in the testing chapter,
since we cover them in the documentation chapter. So make sure people
know that.
Fixes#28082
The original blog post referred to examples by their file names, and now
that it's in guide form, there is no file name. So edit the text so that
it makes a bit more sense.
Fixes#28428
The links in the rustdoc for several places in fmt were trying to link to
the std::fmt module but actually linking to std, which was confusing.
While trying to figure out why I noticed that the documentation chapter of
the Rust book has examples that show this same bug (although it doesn't seem
widespread in practice).
This is part of #28572, but doesn't complete it. Amongst other things,
this patch:
* Increases consistency in the way feature flags are used with other
docs.
* Removes the ignores, which is nice: we actually had some syntax errors
in the examples 😭.
* Mentions #![no_core]
Realistically, this document used to be in the order of least to most:
nothing, then adding core. But with the changes in RFC 1184, this is
backwards: it now shows stuff that uses core from the beginning. In the
future, I'd like to revamp this to go from 'most to least', but I'd like
to see the discussion in https://github.com/rust-lang/rust/issues/27701
goes before I write more.
- Expand the first paragraph
- Improve readability by partitioning the chapter into the following
sections: "Patterns", "Type annotations", "Mutability", and
"Initializing bindings"
- Add "Scope and shadowing" section (fix#28177)
This was non-obvious to me: with no example, I assumed `Electron {}` and
didn't know what else to try when it didn't work. The correct form is
weird because it looks like you're assigning the struct name rather than
an instance of the struct.
r? @steveklabnik
the example for `find` was misleading in that it fails to mention the result is either `None` or `Some` containing only the first match. Further confusing the issue is the `println!` statement, "We got some numbers!"
This wasn't complete (you need a `./configure`), and it is already
documented well in the main README.
Also adds a reference to the books that this also generates.
This was non-obvious to me: with no example, I assumed `Electron {}` and
didn't know what else to try when it didn't work. The correct form is
weird because it looks like you're assigning the struct name rather than
an instance of the struct.
the example for `find` was misleading in that it fails to mention the result is either `None` or `Some` containing only the first match. Further confusing the issue is the `println!` statement, "We got some numbers!"
This adds a new target property, `target_vendor`. It is to be be used as a matcher for conditional compilation. The vendor is part of the [autoconf target triple](http://llvm.org/docs/doxygen/html/classllvm_1_1Triple.html#details): `<arch><sub>-<vendor>-<os>-<env>`. `arch`, `target_os` and `target_env` are already supported by Rust.
This change was suggested in PR #28593. It enables conditional compilation based on the vendor. This is needed for the rumprun target, which needs to match against both, target_os and target_vendor.
The default value for `target_vendor` is "unknown", "apple" and "pc" are other common values.
Matching against the `target_vendor` is introduced behind the feature gate `#![feature(cfg_target_vendor)]`.
This is the first time I messed around with rustc internals. I just added the my code where I found the existing `target_*` variables, hopefully I haven't missed anything. Please review with care. :)
r? @alexcrichton
