Currently any line starting with `#` is filtered from the output,
including line like `#[deriving]`; this patch makes it so lines are only
filtered when followed by a space similar to the current behaviour of
the tutorial/manual tester.
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.
This pull request completely rewrites std::comm and all associated users. Some major bullet points
* Everything now works natively
* oneshots have been removed
* shared ports have been removed
* try_recv no longer blocks (recv_opt blocks)
* constructors are now Chan::new and SharedChan::new
* failure is propagated on send
* stream channels are 3x faster
I have acquired the following measurements on this patch. I compared against Go, but remember that Go's channels are fundamentally different than ours in that sends are by-default blocking. This means that it's not really a totally fair comparison, but it's good to see ballpark numbers for anyway
```
oneshot stream shared1
std 2.111 3.073 1.730
my 6.639 1.037 1.238
native 5.748 1.017 1.250
go8 1.774 3.575 2.948
go8-inf slow 0.837 1.376
go8-128 4.832 1.430 1.504
go1 1.528 1.439 1.251
go2 1.753 3.845 3.166
```
I had three benchmarks:
* oneshot - N times, create a "oneshot channel", send on it, then receive on it (no task spawning)
* stream - N times, send from one task to another task, wait for both to complete
* shared1 - create N threads, each of which sends M times, and a port receives N*M times.
The rows are as follows:
* `std` - the current libstd implementation (before this pull request)
* `my` - this pull request's implementation (in M:N mode)
* `native` - this pull request's implementation (in 1:1 mode)
* `goN` - go's implementation with GOMAXPROCS=N. The only relevant value is 8 (I had 8 cores on this machine)
* `goN-X` - go's implementation where the channels in question were created with buffers of size `X` to behave more similarly to rust's channels.
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
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
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#8674Closes#8318Closes#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#8674Closes#8318Closes#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.
- Cause `0` to be considered a valid integer literal (it is).
- Add octal literals (missed from #10243).
I have *not* modified doc/po/rust.md.pot or doc/po/ja/rust.md.po at all;
they already seem to be out of date so it's easier to ignore them for
myself. I can update them if desired, of course.
I've started working on this issue and pushed a small commit, which adds a range check for integer literals in `middle::const_eval` (no `uint` at the moment)
At the moment, this patch is just a proof of concept, I'm not sure if there is a better function for the checks in `middle::const_eval`. This patch does not check for overflows after constant folding, eg:
let x: i8 = 99 + 99;
Since tutorial/manual files are stored on static.rust-lang.org, browsers
try to fetch the favicon from there while it should be retrieved from the
main domain.
These two attributes are no longer useful now that Rust has decided to leave
segmented stacks behind. It is assumed that the rust task's stack is always
large enough to make an FFI call (due to the stack being very large).
There's always the case of stack overflow, however, to consider. This does not
change the behavior of stack overflow in Rust. This is still normally triggered
by the __morestack function and aborts the whole process.
C stack overflow will continue to corrupt the stack, however (as it did before
this commit as well). The future improvement of a guard page at the end of every
rust stack is still unimplemented and is intended to be the mechanism through
which we attempt to detect C stack overflow.
Closes#8822Closes#10155
This adds an other ABI option which allows a custom selection over the target
architecture and OS. The only current candidate for this change is that kernel32
on win32 uses stdcall, but on win64 it uses the cdecl calling convention.
Otherwise everywhere else this is defined as using the Cdecl calling convention.
cc #10049Closes#8774
This section desperately needs to be expanded, but removing the
misleading/incorrect information is a priority.
Managed vectors/strings are not covered, as they are feature-gated and
are only a micro-optimization to avoid double-indirection.
Closes#6882
This section desperately needs to be expanded, but removing the
misleading/incorrect information is a priority.
Managed vectors/strings are not covered, as they are feature-gated and
are only a micro-optimization to avoid double-indirection.
Closes#6882
This extension can be used to concatenate string literals at compile time. C has
this useful ability when placing string literals lexically next to one another,
but this needs to be handled at the syntax extension level to recursively expand
macros.
The major use case for this is something like:
macro_rules! mylog( ($fmt:expr $($arg:tt)*) => {
error2!(concat!(file!(), ":", line!(), " - ", $fmt) $($arg)*);
})
Where the mylog macro will automatically prepend the filename/line number to the
beginning of every log message.
