| Age | Commit message (Collapse) | Author | Lines |
|---|
|
We generate documentation into the doc/ directory, so we shouldn't be
intermingling source files with generated files
|
|
|
|
|
|
I'm sorry :'(
Closes #11859
|
|
Various functions can now be made specific to ~[], or just non-managed
vectors.
|
|
|
|
This feature already was in the tutorial, but I believe that the tutorial should be a strict subset of the manual.
I also added an example.
|
|
|
|
|
|
Closes #11362.
|
|
|
|
|
|
|
|
Fixes #11559 (not that the manual couldn't use a review).
|
|
|
|
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
Closes #3862
|
|
|
|
Closes #7959.
|
|
The `print!` and `println!` macros are now the preferred method of printing, and so there is no reason to export the `stdio` functions in the prelude. The functions have also been replaced by their macro counterparts in the tutorial and other documentation so that newcomers don't get confused about what they should be using.
|
|
|
|
|
|
I was reading through the tutorial and manual pdfs and noticed some of the code blocks have glitches in their formatting:
Putting empty lines around the blocks fixes this. I did a search through the other markdown files and made the change there as well.
|
|
Code blocks apparently need to be surrounded by whitespace to be output
correctly when generating pdfs
|
|
|
|
Previously this was an rtabort!, indicating a runtime bug. Promote
this to a more intentional abort and print a (slightly) more
informative error message.
Can't test this sense our test suite can't handle an abort exit.
|
|
|
|
#[ author = "Jane Doe" ]; raises "warning: unknown crate attribute"
replace `pkgid` by `crate_id`
add `comment`
|
|
|
|
#[ author = "Jane Doe" ]; raises "warning: unknown crate attribute"
|
|
This change extends the pkgid attribute to allow of explicit crate names, instead of always inferring them based on the path. This means that if your GitHub repo is called `rust-foo`, you can have your pkgid set your library name to `foo`. You'd do this with a pkgid attribute like `github.com/somewhere/rust-foo#foo:1.0`.
This is half of the fix for #10922.
|
|
|
|
|
|
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
rustdoc:
- fix search-bar layout
doc: CSS:
- switch to native pandoc toc depth
- rm some dead code
- clamp width to be readable (we're not Wikipedia!)
- don't background-color titles, it's bloating
- make syntax-highlighting colors inline with rust-lang.org
- space indents
@alexcrichton
|
|
|
|
Clarify that it's sundown, and that we don't support magic
|
|
|
|
Also remove all instances of 'self within the codebase.
This fixes #10889.
|
|
The following files need to be adjusted, too (i can't do it now):
- doc/po/ja/rust.md.po
- doc/po/rust.md.pot
|
|
The section on closure types was missing, so I added one. I'm new to Rust, so there are probably important things to say about closure types that I'm missing here.
I tested the example with the latest Rust nightly.
|
|
|
|
This includes documentation for all the previous changes done to linking
in #10582. Additionally, this brings the list of feature-gates up-to-date with
the currently recognized list of features.
|
|
This commit implements the support necessary for generating both intermediate
and result static rust libraries. This is an implementation of my thoughts in
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006686.html.
When compiling a library, we still retain the "lib" option, although now there
are "rlib", "staticlib", and "dylib" as options for crate_type (and these are
stackable). The idea of "lib" is to generate the "compiler default" instead of
having too choose (although all are interchangeable). For now I have left the
"complier default" to be a dynamic library for size reasons.
Of the rust libraries, lib{std,extra,rustuv} will bootstrap with an
rlib/dylib pair, but lib{rustc,syntax,rustdoc,rustpkg} will only be built as a
dynamic object. I chose this for size reasons, but also because you're probably
not going to be embedding the rustc compiler anywhere any time soon.
Other than the options outlined above, there are a few defaults/preferences that
are now opinionated in the compiler:
* If both a .dylib and .rlib are found for a rust library, the compiler will
prefer the .rlib variant. This is overridable via the -Z prefer-dynamic option
* If generating a "lib", the compiler will generate a dynamic library. This is
overridable by explicitly saying what flavor you'd like (rlib, staticlib,
dylib).
* If no options are passed to the command line, and no crate_type is found in
the destination crate, then an executable is generated
With this change, you can successfully build a rust program with 0 dynamic
dependencies on rust libraries. There is still a dynamic dependency on
librustrt, but I plan on removing that in a subsequent commit.
This change includes no tests just yet. Our current testing
infrastructure/harnesses aren't very amenable to doing flavorful things with
linking, so I'm planning on adding a new mode of testing which I believe belongs
as a separate commit.
Closes #552
|
|
|
|
Previously, `//// foo` and `/*** foo ***/` were accepted as doc comments. This
changes that, so that only `/// foo` and `/** foo ***/` are accepted. This
confuses many newcomers and it seems weird.
Also update the manual for these changes, and modernify the EBNF for comments.
Closes #10638
|
|
This provides a building block for fast thread-local storage. It does
not change the safety semantics of `static mut`.
Closes #10310
|
|
This provides a building block for fast thread-local storage. It does
not change the safety semantics of `static mut`.
Closes #10310
|
|
|
