Originally, this was going to be discussed and revisted, however I've been working on this for months, and a rebase on top of master was about 1 flight's worth of work so I just went ahead and did it.
This gets you as far as being able to target powerpc with, eg:
LD_LIBRARY_PATH=./x86_64-unknown-linux-gnu/stage2/lib/ x86_64-unknown-linux-gnu/stage2/bin/rustc -C linker=powerpc-linux-gnu-gcc --target powerpc-unknown-linux-gnu hello.rs
Would really love to get this out before 1.0. r? @alexcrichton
There is likely to be new users with the alpha release, and there are a lot of documents on the internet (StackOverflow, reddit, blogs) that refer to these guides, so emitting a more helpful error than "404" is nice. Hence, I've temporarily reinstated stub documents for each of the old guides, referring to as relevant a part of the book as possible.
Also, rustbook was silently ignoring some errors, which lead to an inconsistency with directory creation/file writing. This meant the CSS file was not being written if no `doc` directory existed in the users build dir (e.g. the buildbots). This should mean that the CSS will appear automatically in later builds.
Without this, rustbook was failing because it was expecting the
directory to exist. (Previously, rustbook was just silently failing to
install the CSS files due to this.)
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.
