| Age | Commit message (Collapse) | Author | Lines |
|
Also remove all instances of 'self within the codebase.
This fixes #10889.
|
|
Clarify that it's sundown, and that we don't support magic
|
|
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
|
|
Many of them are small. Will squash on request, but I feel like it's easier
for everyone (easier to see and back out individual changes) this way.
|
|
This is literally a copy-paste, there's no need to have this duplication.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Also no longer reference mutable fields
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
typo
|
|
|
|
|
|
|
|
|
|
Reported be @ElBaha
|
|
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
|
|
|
|
This begins a rewrite of some sections the tutorial as an introduction
to concepts through the implementation of a simple data structure. I
think this would be a good way to introduce references, traits and many
other concepts too. For example, the section introducing alternatives to
ownership can demonstrate a persistent list.
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The reasons for doing this are:
* The model on which linked failure is based is inherently complex
* The implementation is also very complex, and there are few remaining who
fully understand the implementation
* There are existing race conditions in the core context switching function of
the scheduler, and possibly others.
* It's unclear whether this model of linked failure maps well to a 1:1 threading
model
Linked failure is often a desired aspect of tasks, but we would like to take a
much more conservative approach in re-implementing linked failure if at all.
Closes #8674
Closes #8318
Closes #8863
|
|
The reasons for doing this are:
* The model on which linked failure is based is inherently complex
* The implementation is also very complex, and there are few remaining who
fully understand the implementation
* There are existing race conditions in the core context switching function of
the scheduler, and possibly others.
* It's unclear whether this model of linked failure maps well to a 1:1 threading
model
Linked failure is often a desired aspect of tasks, but we would like to take a
much more conservative approach in re-implementing linked failure if at all.
Closes #8674
Closes #8318
Closes #8863
|
|
|
|
This replaces the old section on managed pointers because the syntax is
going to be removed and it's currently feature gated so the examples
don't work out-of-the-box. Dynamic mutability coverage can be added
after the `Mut<T>` work has landed.
|
|
This replaces the old section on managed pointers because the syntax is
going to be removed and it's currently feature gated so the examples
don't work out-of-the-box. Dynamic mutability coverage can be added
after the `Mut<T>` work has landed.
|
|
|
|
|