This pulls all of our long-form documentation into a single document,
nicknamed "the book" and formally titled "The Rust Programming
Language."
A few things motivated this change:
* People knew of The Guide, but not the individual Guides. This merges
them together, helping discoverability.
* You can get all of Rust's longform documentation in one place, which
is nice.
* We now have rustbook in-tree, which can generate this kind of
documentation. While its style is basic, the general idea is much
better: a table of contents on the left-hand side.
* Rather than a almost 10,000-line guide.md, there are now smaller files
per section.
This partially implements the feature staging described in the
[release channel RFC][rc]. It does not yet fully conform to the RFC as
written, but does accomplish its goals sufficiently for the 1.0 alpha
release.
It has three primary user-visible effects:
* On the nightly channel, use of unstable APIs generates a warning.
* On the beta channel, use of unstable APIs generates a warning.
* On the beta channel, use of feature gates generates a warning.
Code that does not trigger these warnings is considered 'stable',
modulo pre-1.0 bugs.
Disabling the warnings for unstable APIs continues to be done in the
existing (i.e. old) style, via `#[allow(...)]`, not that specified in
the RFC. I deem this marginally acceptable since any code that must do
this is not using the stable dialect of Rust.
Use of feature gates is itself gated with the new 'unstable_features'
lint, on nightly set to 'allow', and on beta 'warn'.
The attribute scheme used here corresponds to an older version of the
RFC, with the `#[staged_api]` crate attribute toggling the staging
behavior of the stability attributes, but the user impact is only
in-tree so I'm not concerned about having to make design changes later
(and I may ultimately prefer the scheme here after all, with the
`#[staged_api]` crate attribute).
Since the Rust codebase itself makes use of unstable features the
compiler and build system to a midly elaborate dance to allow it to
bootstrap while disobeying these lints (which would otherwise be
errors because Rust builds with `-D warnings`).
This patch includes one significant hack that causes a
regression. Because the `format_args!` macro emits calls to unstable
APIs it would trigger the lint. I added a hack to the lint to make it
not trigger, but this in turn causes arguments to `println!` not to be
checked for feature gates. I don't presently understand macro
expansion well enough to fix. This is bug #20661.
Closes#16678
[rc]: https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md
This is a work in progress, but this should get *extensive* review, so I'm putting it up early and often.
This is the start of a draft of the new 'ownership guide,' which explains ownership, borrowing, etc. I'm feeling better about this framing than last time's, but we'll see.
This is a collection of misc issues I've run into while adding bindir & libdir support that aren't really bindir & libdir specific.
While I continue to fiddle with bindir and libdir bugs, I figured these might be useful for others to have merged.
Right now we'll end up globbing them into the accepted targets and (ever worse) they will override the make variables of real target files because we `include`d everything in that directory.
As a side effect, editors get a better hint on file types.
Fixies #11671
This commit changes default relative libdir 'lib' to a relative libdir calculated using LIBDIR provided by --libdir configuration option. In case if no option was provided behavior does not change.
We have a default value for this ('/usr/local'), so this warning is
printed ALL the time unless one does --enable-local-rust. As a result,
it doesn't really help at all.
not in hardcoded libdir path. If there was no LIBDIR provided
during configuration fallback to hardcoded paths.
Thanks to Jan Niklas Hasse for solution and to Alex Crichton for improvements.
Closes#11671
Removes all target-specific knowledge from rustc. Some targets have changed
during this, but none of these should be very visible outside of
cross-compilation. The changes make our targets more consistent.
iX86-unknown-linux-gnu is now only available as i686-unknown-linux-gnu. We
used to accept any value of X greater than 1. i686 was released in 1995, and
should encompass the bare minimum of what Rust supports on x86 CPUs.
The only two windows targets are now i686-pc-windows-gnu and
x86_64-pc-windows-gnu.
The iOS target has been renamed from arm-apple-ios to arm-apple-darwin.
A complete list of the targets we accept now:
arm-apple-darwin
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
i686-apple-darwin
i686-pc-windows-gnu
i686-unknown-freebsd
i686-unknown-linux-gnu
mips-unknown-linux-gnu
mipsel-unknown-linux-gnu
x86_64-apple-darwin
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu
x86_64-pc-windows-gnu
Closes#16093
[breaking-change]
Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code. When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.
----
As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully. (If we cannot run
`rustc`, we really shouldn't try to keep going.)
----
Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.
----
Fix#17887.
This commit removes the libuv and gyp submodules, as well as all build
infrastructure related to them.
For more context, see the [runtime removal
RFC](https://github.com/rust-lang/rfcs/pull/230)
[breaking-change]
Adds a new configure flag, --release-channel, which determines how the version
number should be augmented with a release label, as well as how the distribution
artifacts will be named. This is entirely for use by the build automation.
--release-channel can be either 'source', 'nightly', 'beta', or 'stable'.
Here's a summary of the affect of these values on version number and
artifact naming, respectively:
* source - '0.12.0-pre', 'rust-0.12.0-pre-...'
* nightly - '0.12.0-nightly', 'rust-nightly-...'
* beta - '0.12.0-beta', 'rust-beta-...'
* stable - '0.12.0', 'rust-0.12.0-...'
Per http://discuss.rust-lang.org/t/rfc-impending-changes-to-the-release-process/508/1
