Previously an ExprLit was created *per byte* causing a huge increase in memory
bloat. This adds a new `lit_binary` to contain a literal of binary data, which
is currently only used by the include_bin! syntax extension. This massively
speeds up compilation times of the shootout-k-nucleotide-pipes test
before:
time: 469s
memory: 6GB
assertion failure in LLVM (section too large)
after:
time: 2.50s
memory: 124MB
Closes#2598
Previously an ExprLit was created *per byte* causing a huge increase in memory
bloat. This adds a new `lit_binary` to contain a literal of binary data, which
is currently only used by the include_bin! syntax extension. This massively
speeds up compilation times of the shootout-k-nucleotide-pipes test
before:
time: 469s
memory: 6GB
assertion failure in LLVM (section too large)
after:
time: 2.50s
memory: 124MB
Closes#2598
r? @metajack rustpkg now makes source files that it checks out automatically read-only, and stores
them under build/.
Also, refactored the `PkgSrc` type to keep track of separate source and destination
workspaces, as well as to have a `build_workspace` method that returns the workspace
to put temporary files in (usually the source, sometimes the destination -- see
comments for more details).
Closes#6480
rustpkg now makes source files that it checks out automatically read-only, and stores
them under build/.
Also, refactored the `PkgSrc` type to keep track of separate source and destination
workspaces, as well as to have a `build_workspace` method that returns the workspace
to put temporary files in (usually the source, sometimes the destination -- see
comments for more details).
Closes#6480
This removes the warning "Note" about visibility not being fully defined, as it
should now be considered fully defined with further bugs being considered just
bugs in the implementation.
This implements the necessary logic for gating particular features off by default in the compiler. There are a number of issues which have been wanting this form of mechanism, and this initially gates features which we have open issues for.
Additionally, this should unblock #9255
A few features are now hidden behind various #[feature(...)] directives. These
include struct-like enum variants, glob imports, and macro_rules! invocations.
Closes#9304Closes#9305Closes#9306Closes#9331
It is simply defined as `f64` across every platform right now.
A use case hasn't been presented for a `float` type defined as the
highest precision floating point type implemented in hardware on the
platform. Performance-wise, using the smallest precision correct for the
use case greatly saves on cache space and allows for fitting more
numbers into SSE/AVX registers.
If there was a use case, this could be implemented as simply a type
alias or a struct thanks to `#[cfg(...)]`.
Closes#6592
The mailing list thread, for reference:
https://mail.mozilla.org/pipermail/rust-dev/2013-July/004632.html
the switch from package `hello` to `pkg_id` is a little jarring; I'd use `<var>` but I don't see how. ALL_CAPS i.e. PKG_ID seems like a reasonable poor-man's `<var>`.
the switch from package `hello` to `rust_pkg` is a little jarring; I'd use <var> but I don't see how. ALL_CAPS seems like a reasonable poor-man's <var>.
Three things in this commit:
1. Actually build the rustpkg tutorial. I didn't know I needed this when
I first wrote it.
2. Link to it rather than the manual from the
tutorial.
3. Update the headers: most of them were one level too deeply
nested.
Three things in this commit:
1. Actually build the rustpkg tutorial. I didn't know I needed this when
I first wrote it.
2. Link to it rather than the manual from the
tutorial.
3. Update the headers: most of them were one level too deeply
nested.
Many people will be very confused that their debug! statements aren't working
when they first use rust only to learn that they should have been building with
`--cfg debug` the entire time. This inverts the meaning of the flag to instead
of enabling debug statements, now it disables debug statements.
This way the default behavior is a bit more reasonable, and requires less
end-user configuration. Furthermore, this turns on debug by default when
building the rustc compiler.
Many people will be very confused that their debug! statements aren't working
when they first use rust only to learn that they should have been building with
`--cfg debug` the entire time. This inverts the meaning of the flag to instead
of enabling debug statements, now it disables debug statements.
This way the default behavior is a bit more reasonable, and requires less
end-user configuration. Furthermore, this turns on debug by default when
building the rustc compiler.
`deque` -> `ringbuf`, mention `extra::dlist`.
fix reference to vector method `bsearch`. Also convert all output
in example code to use `print!`/`println!`
This commit adds support for `\0` escapes in character and string literals.
Since `\0` is equivalent to `\x00`, this is a direct translation to the latter
escape sequence. Future builds will be able to compile using `\0` directly.
Also updated the grammar specification and added a test for NUL characters.
This doesn't close any bugs as the goal is to convert the parameter to by-value, but this is a step towards being able to make guarantees about `&T` pointers (where T is Freeze) to LLVM.
First shot at a new tutorial for rustpkg. /cc @catamorphism
Right now, I'm linking to my sample package on GitHub, I'm not sure that everyone would be comfortable with me having that there. Maybe under the mozilla org? I think having one to install and hold up as a default makes sense.
This module was removed a while ago, but the tasks tutorial wasn't
updated, and the old docs page for pipes was never deleted so the link
confusingly still worked!
This module was removed a while ago, but the tasks tutorial wasn't
updated, and the old docs page for pipes was never deleted so the link
confusingly still worked!
Remove these in favor of the two traits themselves and the wrapper
function std::from_str::from_str.
Add the function std::num::from_str_radix in the corresponding role for
the FromStrRadix trait.
This is a series of patches to modernize option and result. The highlights are:
* rename `.unwrap_or_default(value)` and etc to `.unwrap_or(value)`
* add `.unwrap_or_default()` that uses the `Default` trait
* add `Default` implementations for vecs, HashMap, Option
* add `Option.and(T) -> Option<T>`, `Option.and_then(&fn() -> Option<T>) -> Option<T>`, `Option.or(T) -> Option<T>`, and `Option.or_else(&fn() -> Option<T>) -> Option<T>`
* add `option::ToOption`, `option::IntoOption`, `option::AsOption`, `result::ToResult`, `result::IntoResult`, `result::AsResult`, `either::ToEither`, and `either::IntoEither`, `either::AsEither`
* renamed `Option::chain*` and `Result::chain*` to `and_then` and `or_else` to avoid the eventual collision with `Iterator.chain`.
* Added a bunch of impls of `Default`
* Added a `#[deriving(Default)]` syntax extension
* Removed impls of `Zero` for `Option<T>` and vecs.
As per rustpkg.md, rustpkg now builds in a target-specific
subdirectory of build/, and installs libraries into a target-specific
subdirectory of lib.
Closes#8672
The old documentation for for loops/expressions has been quite wrong since the change to iterators. This updates the docs to make them relevant to how for loops work now, if not very in-depth. There may be a need for updates giving more depth on how they work, such as detailing what method calls they make, but I don't know enough about the implementation to include that.
The trait will keep the `Iterator` naming, but a more concise module
name makes using the free functions less verbose. The module will define
iterables in addition to iterators, as it deals with iteration in
general.
There are 6 new compiler recognised attributes: deprecated, experimental,
unstable, stable, frozen, locked (these levels are taken directly from
Node's "stability index"[1]). These indicate the stability of the
item to which they are attached; e.g. `#[deprecated] fn foo() { .. }`
says that `foo` is deprecated.
This comes with 3 lints for the first 3 levels (with matching names) that
will detect the use of items marked with them (the `unstable` lint
includes items with no stability attribute). The attributes can be given
a short text note that will be displayed by the lint. An example:
#[warn(unstable)]; // `allow` by default
#[deprecated="use `bar`"]
fn foo() { }
#[stable]
fn bar() { }
fn baz() { }
fn main() {
foo(); // "warning: use of deprecated item: use `bar`"
bar(); // all fine
baz(); // "warning: use of unmarked item"
}
The lints currently only check the "edges" of the AST: i.e. functions,
methods[2], structs and enum variants. Any stability attributes on modules,
enums, traits and impls are not checked.
[1]: http://nodejs.org/api/documentation.html
[2]: the method check is currently incorrect and doesn't work.
Document the fact that the iterator protocol only defines behavior up
until the first None is returned. After this point, iterators are free
to behave how they wish.
Add a new iterator adaptor Fuse<T> that modifies iterators to return
None forever if they returned None once.
in the rust grammar
to avoid error messages like this:
Exception: non-alpha apparent keyword: pub"
when using extract_grammar.py:
python2.7 src/etc/extract_grammar.py <doc/rust.md
Signed-off-by: Jan Kobler <eng1@koblersystems.de>
If they are on the trait then it is extremely annoying to use them as
generic parameters to a function, e.g. with the iterator param on the trait
itself, if one was to pass an Extendable<int> to a function that filled it
either from a Range or a Map<VecIterator>, one needs to write something
like:
fn foo<E: Extendable<int, Range<int>> +
Extendable<int, Map<&'self int, int, VecIterator<int>>>
(e: &mut E, ...) { ... }
since using a generic, i.e. `foo<E: Extendable<int, I>, I: Iterator<int>>`
means that `foo` takes 2 type parameters, and the caller has to specify them
(which doesn't work anyway, as they'll mismatch with the iterators used in
`foo` itself).
This patch changes it to:
fn foo<E: Extendable<int>>(e: &mut E, ...) { ... }
If they are on the trait then it is extremely annoying to use them as
generic parameters to a function, e.g. with the iterator param on the trait
itself, if one was to pass an Extendable<int> to a function that filled it
either from a Range or a Map<VecIterator>, one needs to write something
like:
fn foo<E: Extendable<int, Range<int>> +
Extendable<int, Map<&'self int, int, VecIterator<int>>>
(e: &mut E, ...) { ... }
since using a generic, i.e. `foo<E: Extendable<int, I>, I: Iterator<int>>`
means that `foo` takes 2 type parameters, and the caller has to specify them
(which doesn't work anyway, as they'll mismatch with the iterators used in
`foo` itself).
This patch changes it to:
fn foo<E: Extendable<int>>(e: &mut E, ...) { ... }
r? @graydon Also, notably, make rustpkgtest depend on the rustpkg executable (otherwise, tests that shell out to rustpgk might run when rustpkg doesn't exist).
This commit allows you to write:
extern mod x = "a/b/c";
which means rustc will search in the RUST_PATH for a package with
ID a/b/c, and bind it to the name `x` if it's found.
Incidentally, move get_relative_to from back::rpath into std::path
This is a fairly large rollup, but I've tested everything locally, and none of
it should be platform-specific.
r=alexcrichton (bdfdbdd)
r=brson (d803c18)
r=alexcrichton (a5041d0)
r=bstrie (317412a)
r=alexcrichton (135c85e)
r=thestinger (8805baa)
r=pcwalton (0661178)
r=cmr (9397fe0)
r=cmr (caa4135)
r=cmr (6a21d93)
r=cmr (4dc3379)
r=cmr (0aa5154)
r=cmr (18be261)
r=thestinger (f10be03)
Code like this is fixed now:
```
fn foo(p: [u8, ..4]) {
match p {
[a, b, c, d] => {}
};
}
```
Invalid constructors are not reported as errors yet:
```
fn foo(p: [u8, ..4]) {
match p {
[_, _, _] => {} // this should be error
[_, _, _, _, _, .._] => {} // and this
_ => {}
}
}
```
Issue #8311 is partially fixed by this commit. Fixed-length arrays in
let statement are not yet allowed:
```
let [a, b, c] = [1, 2, 3]; // still fails
```
This module provided adaptors for the old internal iterator protocol,
but they proved to be quite unreadable and are not generic enough to
handle borrowed pointers well.
Since Rust no longer defines an internal iteration protocol, I don't
think there's going to be any reuse via these adaptors.
This is preparation for removing `@fn`.
This does *not* use default methods yet, because I don't know
whether they work. If they do, a forthcoming PR will use them.
This also changes the precedence of `as`.
Change the former repetition::
for 5.times { }
to::
do 5.times { }
.times() cannot be broken with `break` or `return` anymore; for those
cases, use a numerical range loop instead.
r? @graydon Package IDs can now be of the form a/b/c#FOO, where (if a/b/c is
a git repository) FOO is any tag in the repository. Non-numeric
tags only match against package IDs with the same tag, and aren't
compared linearly like numeric versions.
While I was at it, refactored the code that calls `git clone`, and segregated build output properly for different packages.
To be more specific:
`UPPERCASETYPE` was changed to `UppercaseType`
`type_new` was changed to `Type::new`
`type_function(value)` was changed to `value.method()`
The free-standing functions in f32, f64, i8, i16, i32, i64, u8, u16,
u32, u64, float, int, and uint are replaced with generic functions in
num instead.
This means that instead of having to know everywhere what the type is, like
~~~
f64::sin(x)
~~~
You can simply write code that uses the type-generic versions in num instead, this works for all types that implement the corresponding trait in num.
~~~
num::sin(x)
~~~
Note 1: If you were previously using any of those functions, just replace them
with the corresponding function with the same name in num.
Note 2: If you were using a function that corresponds to an operator, use the
operator instead.
Note 3: This is just https://github.com/mozilla/rust/pull/7090 reopened against master.
Apparently yesterday wasn't my day, and I forgot to add the changes to
all the tests apparently, and in the end forgot the docs extra much.
Please documentation, forgive me, I really do love you, I hope you
forgive me.
Next time we'll meet tutorial, I promise to bring cookies and tea. I
really want to be best-friends-forever with you, <3.
XOXO
As per https://mail.mozilla.org/pipermail/rust-dev/2013-July/004685.html
This is the initial machinery to setup the l10n infrastructure for markdown documentation.
A new "docs-l10n" target will take care of generating, updating and then building .pot and .po files, and later on the final .md.
This commit includes the .pot for all current .md docs; they can be feed directly to Mozilla Verbatim if wanted.
Please note that po4a only provides the orig.md -> .pot -> l10n.po -> l10n.md flow. The l10n.md -> l10n.html generation is not currently built in the makefile, as no language has been enabled.
These files are automatically genereated by `make docs-l10n` (via po4a),
which will also take of updating them if the original .md changes.
Signed-off-by: Luca Bruno <lucab@debian.org>
This commit add a new "docs-l10n" make target which uses po4a to:
* create .pot (PO templates) from markdown doc
* update templates and po for enabled languages
* generate translated markdown for completed (> 80%) translations
Currently, no language has been activated.
Signed-off-by: Luca Bruno <lucab@debian.org>
