auto merge of #9557 : blake2-ppc/rust/vec-lifetime-token, r=thestinger
std::vec: Use a valid value as lifetime dummy in iterator
The current implementation uses `&v[0]` for the lifetime struct field,
but that is a dangling pointer for iterators derived from zero-length
slices.
Example:
let v: [int, ..0] = []; println!("{:?}", v.iter())
std::vec::VecIterator<,int>{ptr: (0x7f3768626100 as *()), end: (0x7f3768626100 as *()), lifetime: &139875951207128}
To replace this parameter, use a field of type `Option<&'self ()>`
that is simply initialized with `None`, but still allows the iterator to
have a lifetime parameter.
auto merge of #9544 : alexcrichton/rust/clean-docs, r=pnkfelix
This purges doc/{std,extra} entirely during a `make clean` instead of just the
html files in some top level directories. This should help old documentation
from showing up on static.rust-lang.org
Alex Crichton [Thu, 26 Sep 2013 22:13:03 +0000 (15:13 -0700)]
mk: Fully clean out old documentation
This purges doc/{std,extra} entirely during a `make clean` instead of just the
html files in some top level directories. This should help old documentation
from showing up on static.rust-lang.org
auto merge of #9535 : alexcrichton/rust/no-format-default, r=thestinger
As mentioned in #9456, the format! syntax extension would previously consider an
empty format as a 'Unknown' format which could then also get coerced into a
different style of format on another argument.
This is unusual behavior because `{}` is a very common format and if you have
`{0} {0:?}` you wouldn't expect them both to be coereced to the `Poly`
formatter. This commit removes this coercion, but still retains the requirement
that each argument has exactly one format specified for it (an empty format now
counts as well).
Perhaps at a later date we can add support for multiple formats of one argument,
but this puts us in at least a backwards-compatible situation if we decide to do
that.
Alex Crichton [Thu, 26 Sep 2013 20:44:54 +0000 (13:44 -0700)]
Remove the notion of an "unknown format"
As mentioned in #9456, the format! syntax extension would previously consider an
empty format as a 'Unknown' format which could then also get coerced into a
different style of format on another argument.
This is unusual behavior because `{}` is a very common format and if you have
`{0} {0:?}` you wouldn't expect them both to be coereced to the `Poly`
formatter. This commit removes this coercion, but still retains the requirement
that each argument has exactly one format specified for it (an empty format now
counts as well).
Perhaps at a later date we can add support for multiple formats of one argument,
but this puts us in at least a backwards-compatible situation if we decide to do
that.
auto merge of #9538 : thestinger/rust/type_use, r=pcwalton
This is broken, and results in poor performance due to the undefined
behaviour in the LLVM IR. LLVM's `mergefunc` is a *much* better way of
doing this since it merges based on the equality of the bytecode.
For example, consider `std::repr`. It generates different code per
type, but is not included in the type bounds of generics.
The `mergefunc` pass works for most of our code but currently hits an
assert on libstd. It is receiving attention upstream so it will be
ready soon, but I don't think removing this broken code should wait any
longer. I've opened #9536 about enabling it by default.
One of the downsides with `c_str` is that it always forces an allocation, and so this could add unnecessary overhead to various calls. This PR implements one of the suggestions @graydon made in #8296 for `vec.with_c_str` in that for a short string can use a small stack array instead of a malloced array for our temporary c string. This ends up being twice as fast for small strings.
There are two things to consider before landing this commit though. First off, I arbitrarily picked the stack array as 32 bytes, and I'm not sure if this a reasonable amount or not. Second, there is a risk that someone can keep a reference to the interior stack pointer, which could cause mayhem if someone were to dereference the pointer. Since we also can easily grab and return interior pointers to vecs though, I don't think this is that much of an issue.
std::vec: Use a valid value as lifetime dummy in iterator
The current implementation uses `&v[0]` for the lifetime struct field,
but that is a dangling pointer for iterators derived from zero-length
slices.
Example:
let v: [int, ..0] = []; println!("{:?}", v.iter())
std::vec::VecIterator<,int>{ptr: (0x7f3768626100 as *()), end: (0x7f3768626100 as *()), lifetime: &139875951207128}
To replace this parameter, use a field of type `Option<&'self ()>`
that is simply initialized with `None`, but still allows the iterator to
have a lifetime parameter.
auto merge of #9261 : alexcrichton/rust/logging, r=huonw
This lifts various restrictions on the runtime, for example the character limit
when logging a message. Right now the old debug!-style macros still involve
allocating (because they use fmt! syntax), but the new debug2! macros don't
involve allocating at all (unless the formatter for a type requires allocation.
auto merge of #9484 : alexcrichton/rust/fix-cfg-inner-item, r=pcwalton
If an item is skipped due to it being unreachable or for some optimization, then
it shouldn't be encoded into the metadata (because it wasn't present in the
first place).
Daniel Micay [Thu, 26 Sep 2013 20:54:15 +0000 (16:54 -0400)]
remove type_use
This is broken, and results in poor performance due to the undefined
behaviour in the LLVM IR. LLVM's `mergefunc` is a *much* better way of
doing this since it merges based on the equality of the bytecode.
For example, consider `std::repr`. It generates different code per
type, but is not included in the type bounds of generics.
The `mergefunc` pass works for most of our code but currently hits an
assert on libstd. It is receiving attention upstream so it will be
ready soon, but I don't think removing this broken code should wait any
longer. I've opened #9536 about enabling it by default.
Alex Crichton [Wed, 25 Sep 2013 01:18:40 +0000 (18:18 -0700)]
Ensure that skipped items aren't encoded
If an item is skipped due to it being unreachable or for some optimization, then
it shouldn't be encoded into the metadata (because it wasn't present in the
first place).
Alex Crichton [Thu, 26 Sep 2013 18:57:25 +0000 (11:57 -0700)]
rustdoc: Generate documentation for foreign items
This slurps up everything inside of an 'extern' block into the enclosing module
in order to document them. The documentation must be on the items themselves,
and they'll show up next to everything else on the module index pages.
auto merge of #9507 : brson/rust/sched, r=alexcrichton
This also includes a fix for yielding from single-threaded schedulers where the scheduler would stop working before its work queue was empty. Fixes the deadlocks that this patch had previously.
Fix ICE caused by my previous patch, that is, if super trait had more
methods tnan subtrait, compiling would fail. I simply forgot to update
variable name. Updated test case , too.
auto merge of #9500 : fhahn/rust/rename-str_from_bytes-fix, r=alexcrichton
As @Dretch pointed out [here](https://github.com/fhahn/rust/commit/de39874801761197bf10bf8d04bde1aa2bd82e15#L2L526) , from_bytes was accidentally renamed to from_utf8.
auto merge of #9497 : pnkfelix/rust/fsk-7752-use-fcnptr-for-glob-errfunc, r=cmr
Fix #7752.
~~(The glob API is a little funky; I tried to make a small test for it, which I'll add to the end of this description, and its not clear whether globfree is supposed to free solely the structure allocated by glob itself, or if it is going to try to free more than that.)~~ (The previous note was a user-error: I was misusing the CString API.)
Anyway, this seems to work in terms of calling errfunc where expected.)
```rust
#[allow(unused_imports)];
use std::libc::types::os::arch::c95::{c_char, c_int, size_t};
use std::libc::funcs::posix01::glob;
use std::libc::types::os::common::posix01::glob_t;
use std::libc::consts::os::posix01::{GLOB_APPEND, GLOB_DOOFFS, GLOB_ERR,
GLOB_MARK, GLOB_NOCHECK, GLOB_NOSORT,
GLOB_NOESCAPE, GLOB_NOSPACE,
GLOB_ABORTED, GLOB_NOMATCH};
use std::ptr;
use std::c_str;
println!("g: {:?}", Reduced::from(&g));
for i in range(0, g.gl_pathc as int) {
unsafe {
let p : **c_char = ptr::offset(g.gl_pathv, g.gl_offs as int + i);
let x = c_str::CString::new(*p, false);
match x.as_str() {
Some(s) => {
println!("gl_pathc[{:d}]: {:?}", i, s);
}
None => {
println!("gl_pathc[{:d}]: unvalid", i);
}
}
}
}
}
This solves problem of incorrect indexing into vtable
when method from super trait was called through pointer
to derived trait.
Problem was that offset of super trait vtables
was not calculated at all.
Now it works, correct offset is calculated by
traversing all super traits up to super trait
where method belongs. That is how it is
intended to work.
auto merge of #9490 : alexcrichton/rust/issue-9487, r=cmr
If there's no TLS key just yet, then there's nothing to unsafely borrow, so
continue returning None. This prevents causing the runtime to abort itself when
logging before the runtime is fully initialized.
auto merge of #9392 : Kimundi/rust/str_docs, r=cmr
Moved `StrSlice` doc comments from impl to trait.
Moved `OwnedStr` doc comments from impl to trait.
Normalized a few `StrSlice` method names from `FOO_reverse`, `FOO_rev` and `rFOO` to `FOO_rev`.
Added a few `#[inline]` hints.
The doc comment changes make the source a bit harder to read, as documentation and implementation no longer live right next to each other. But this way they at least appear in the docs.
Moved StrSlice doc comments from impl to trait.
Moved OwnedStr doc comments from impl to trait.
Added a few #[inline] hints.
The doc comment changes make the source a bit harder to read, as
documentation and implementation no longer live right next to each
other. But this way they at least appear in the docs.
Alex Crichton [Wed, 28 Aug 2013 08:33:48 +0000 (01:33 -0700)]
Refactor the logging system for fewer allocations
This lifts various restrictions on the runtime, for example the character limit
when logging a message. Right now the old debug!-style macros still involve
allocating (because they use fmt! syntax), but the new debug2! macros don't
involve allocating at all (unless the formatter for a type requires allocation.
auto merge of #9475 : alexcrichton/rust/rustdoc++, r=cmr
The commit messages are a good technical summary, a good visual summary (contrib is this version):
Pub use statements now rendered. Notice how almost all components are also clickable!
* http://static.rust-lang.org/doc/master/std/prelude/index.html
* http://www.contrib.andrew.cmu.edu/~acrichto/doc/std/prelude/index.html
Private things hidden by default (for at least some approximation of privacy). I hope to improve this once privacy is totally ironed out.
* http://static.rust-lang.org/doc/master/std/hashmap/struct.HashMap.html
* http://www.contrib.andrew.cmu.edu/~acrichto/doc/std/hashmap/struct.HashMap.html
Unindentation now works properly:
* http://static.rust-lang.org/doc/master/extra/getopts/index.html
* http://www.contrib.andrew.cmu.edu/~acrichto/doc/extra/getopts/index.html
Also sundown has massively reduced compilation time (of docs, not the of the crates)
Alex Crichton [Tue, 24 Sep 2013 20:55:22 +0000 (13:55 -0700)]
rustdoc: Implement stripping based on privacy
This will probably need to get tweaked once the privacy rules have been fully
agreed on, but for now this has all of the infrastructure necessary for
filtering out private items.
Alex Crichton [Mon, 23 Sep 2013 23:25:58 +0000 (16:25 -0700)]
rustdoc: Add the ability to list all passes
In doing so, also remove the collapse-privacy pass because it's a little
over-zealous and may not be right 100% of the time (not used right now as well)
Alex Crichton [Mon, 23 Sep 2013 21:18:26 +0000 (14:18 -0700)]
rustdoc: Improve comment stripping
There is less implicit removal of various comment styles, and it also removes
extraneous stars occasionally found in docblock comments. It turns out that the
bug for getops was just a differently formatted block.
projects / rust.git / log