There are hundreds of stackoverflow answers, reddit posts and blog
articles that link to these documents, so it's a nicer user experience
if they're not plain 404s.
The intention is to let these hang around only for relatively short
while. The alpha is likely to bring in many new users and they will be
reading the documents mentioned above.
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
After 8b3c67690c the `make install`
command fails if docs are not disabled through CFG_DISABLE_DOCS,
because now the `install` target uses
../../tmp/dist/$(DOC_PKG_NAME)-$(CFG_BUILD)/install.sh
Instead of explicitly depending on
dist/$(PKG_NAME)-$(CFG_BUILD).tar.gz, the `prepare_[un]install`
targets now depend on `dist-tar-bins`, which packages the appropriate
dist archives depending on the configuration.
This removes a large array of deprecated functionality, regardless of how
recently it was deprecated. The purpose of this commit is to clean out the
standard libraries and compiler for the upcoming alpha release.
Some notable compiler changes were to enable warnings for all now-deprecated
command line arguments (previously the deprecated versions were silently
accepted) as well as removing deriving(Zero) entirely (the trait was removed).
The distribution no longer contains the libtime or libregex_macros crates. Both
of these have been deprecated for some time and are available externally.
After 8b3c67690c the `make install`
command fails if docs are not disabled through CFG_DISABLE_DOCS,
because now the `install` target uses
../../tmp/dist/$(DOC_PKG_NAME)-$(CFG_BUILD)/install.sh
In 714a2c678c the `prepare_install`
target wwas changed to conditionally depend also on the doc archive,
but did not modify `prepare_uninstall`.
Instead of explicitly depending on
dist/$(PKG_NAME)-$(CFG_BUILD).tar.gz, the `prepare_[un]install`
targets now depend on `dist-tar-bins`, which packages the appropriate
dist archives depending on the configuration.
Adds a new 'beta cycle' variable that can be appended to the '-beta' version label, e.g. '-beta1'. Changes the version label for the beta channel temporarily to 'alpha'. Changes the artifact name of the beta channel to contain the version number instead of just being called 'beta'. The beta cycle number is currently set to 1.
The impact of this is that the first alphas will be called '1.0.0-alpha1' and the artifacts will also be called '1.0.0-alpha1-*.tar.gz'. We could alternately leave out the cycle number if we are confident there will be only one alpha cycle.
r? @alexcrichton cc @nikomatsakis @huonw
This distributes docs in a separate package called rust-docs. The rust-packaging
project will combine it with Rust and Cargo into a single installer in a variety of formats.
I would like to look into some issues related to the model lexer #15883.
I stumbled upon 2 minor problems when I tried running the lexer tests:
* antlr did not put the generated files in the correct directory
* grammer/verify.rs did not work with the most recent version of rust
With these changes (and setting CLASSPATH=/usr/share/java/antlr-4.4-complete.jar:$CLASSPATH) I was able to execute the tests.
Note that I just fixed the syntax errors and added `None` as 2. argument of `Literal`. I am not sure if this is correct however. I still have to take a closer look at what verify.rs actually does. Are there any helpful pointers?
These crates are all deprecated for their rust-lang/$crate equivalents and by
generating docs we're generating broken links. The documentation for these
crates are generated out-of-tree and are managed separately, so we're not losing
the documentation altogether, just the links from the main distribution's docs.
Closes#20096
It's quite possible that small programs don't use all of jemalloc, and building
with -ffunction-sections and -fdata-sections allows the linker (via
--gc-sections) to strip out all unused code at link time. This decreases the
size of a "hello world" executable for me from 716K to 482K with no measurable
impact on link time. After this patch jemalloc is still the largest portion of
our hello world executables, but this helps cut down on the size at least
somewhat!
It's quite possible that small programs don't use all of jemalloc, and building
with -ffunction-sections and -fdata-sections allows the linker (via
--gc-sections) to strip out all unused code at link time. This decreases the
size of a "hello world" executable for me from 716K to 482K with no measurable
impact on link time. After this patch jemalloc is still the largest portion of
our hello world executables, but this helps cut down on the size at least
somewhat!
In the HTML version of the documentation, it isn't rendered so might as well use the unicode representation.
Part of the problem was that putting a math unicode character wasn't
rendering properly in the pdf, so extra steps were needed to define
the unicode charecter ⊥ in reference.tex
closes#15285
This commit merges the `rustrt` crate into `std`, undoing part of the
facade. This merger continues the paring down of the runtime system.
Code relying on the public API of `rustrt` will break; some of this API
is now available through `std::rt`, but is likely to change and/or be
removed very soon.
[breaking-change]
If you configure with `--disable-docs`, the `doc` directory does not get generated, so
`cp -r doc dist/` fails when you `make dist{,-tar-bins,-doc}` or `make install`
Fix `make TAGS.emacs`.
@nikomatsakis has been complaining to me about this. (I had not noticed since I drive `ctags` with a separate script.)
(Suitable for a rollup build.)
Makes a couple changes that support the implementation of a REPL:
* Implementation of wrapper code for LLVM ExecutionEngine API
* Fixing a change I made earlier to reset compiler state in `phase_1_[...]`
instead of `compile_input` as the latter is not used in a REPL
- Support gcc-less installation on Windows. To do so in unattended mode run:`<intaller>.exe /TYPE=compact /SILENT`.
- Do not require admin privileges to install.
cc #19519
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.
I stumbled across this today, and it's not really working. It's been around for a very, very long time, and seems to be based on stuff we don't even have anymore.
I asked in `#rust-internals`, and @cmr said we should just kill it, so here I am. :) I don't think that anything else uses Java, but maybe I missed something.
And if this _isn't_ what we want, I'm fine with closing too. Just some housekeeping.
This patch merges the `libsync` crate into `libstd`, undoing part of the
facade. This is in preparation for ultimately merging `librustrt`, as
well as the upcoming rewrite of `sync`.
Because this removes the `libsync` crate, it is a:
[breaking-change]
However, all uses of `libsync` should be able to reroute through
`std::sync` and `std::comm` instead.
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 add CFG_LLVM_TARGET_$(target) (which can be defined in any of the
mk/cfg/* files) and supply a default to the plain target name
CFG_LLVM_TARGET mirrors the value of llvm_target (aka llvm-target) in
the librustc_back runtime target specification.
Without this, if we we're using a non-standard host libdir, the target
bindir would not exist (and rustc would fail to write to the
non-existent directory).
If the expected rustc snapshot is not where we expect it to be,
complain and fail at that point rather than creating a empty rustc file
and continuing until we try to run it.
Futureproof Rust for fancier suffixed literals. The Rust compiler tokenises a literal followed immediately (no whitespace) by an identifier as a single token: (for example) the text sequences `"foo"bar`, `1baz` and `1u1024` are now a single token rather than the pairs `"foo"` `bar`, `1` `baz` and `1u` `1024` respectively.
The compiler rejects all such suffixes in the parser, except for the 12 numeric suffixes we have now.
I'm fairly sure this will affect very few programs, since it's not currently legal to have `<literal><identifier>` in a Rust program, except in a macro invocation. Any macro invocation relying on this behaviour can simply separate the two tokens with whitespace: `foo!("bar"baz)` becomes `foo!("bar" baz)`.
This implements [RFC 463](https://github.com/rust-lang/rfcs/blob/master/text/0463-future-proof-literal-suffixes.md), and so closes https://github.com/rust-lang/rust/issues/19088.
Now that we've done `fail` -> `panic`, I feel bringing back the error handling guide is a good idea. We had one long ago, but it was removed when conditions were removed.
This doesn't cover the new FromError stuff, but I feel like it's already useful in this state, so I'm sending this PR now.
