bors [Wed, 6 Aug 2014 21:56:07 +0000 (21:56 +0000)]
auto merge of #16225 : pczarn/rust/iter-refactoring, r=kballard
Simplifying the code of methods: `nth`, `fold`, `rposition`, and iterators: `Filter`, `FilterMap`, `SkipWhile`.
```
before
test iter::bench_multiple_take ... bench: 15 ns/iter (+/- 0)
test iter::bench_rposition ... bench: 349 ns/iter (+/- 94)
test iter::bench_skip_while ... bench: 158 ns/iter (+/- 6)
after
test iter::bench_multiple_take ... bench: 15 ns/iter (+/- 0)
test iter::bench_rposition ... bench: 314 ns/iter (+/- 2)
test iter::bench_skip_while ... bench: 107 ns/iter (+/- 0)
```
@koalazen has the code for `Skip`.
Once #16011 is fixed, `min_max` could use a for loop.
bors [Wed, 6 Aug 2014 15:51:19 +0000 (15:51 +0000)]
auto merge of #15865 : jamesrhurst/rust/ctags-regex, r=alexcrichton
Previously the implementation detection regex would detect
`impl fmt::Show for MyStruct` as `fmt`. Now it will be detected as
`fmt::Show for MyStruct`. Implementations such as `impl MyStruct` will
still be detected as `MyStruct`.
bors [Wed, 6 Aug 2014 08:31:28 +0000 (08:31 +0000)]
auto merge of #16258 : aturon/rust/stabilize-atomics, r=alexcrichton
This commit stabilizes the `std::sync::atomics` module, renaming it to
`std::sync::atomic` to match library precedent elsewhere, and tightening
up behavior around incorrect memory ordering annotations.
The vast majority of the module is now `stable`. However, the
`AtomicOption` type has been deprecated, since it is essentially unused
and is not truly a primitive atomic type. It will eventually be replaced
by a higher-level abstraction like MVars.
bors [Wed, 6 Aug 2014 04:56:25 +0000 (04:56 +0000)]
auto merge of #16254 : brson/rust/rustdocmeta, r=aturon
This teach rustdoc to add `<meta name="description">` and `<meta name="keywords">` tags to crate docs. Description is important for search engines because they display it as the page description. Keywords are less useful but still generally recommended.
This also changes the "stability dashboard" link to just say "stability", because the current link takes up a lot of space.
Alex Crichton [Wed, 6 Aug 2014 02:51:02 +0000 (19:51 -0700)]
rustdoc: Run all work in a separate task
There's a good long comment explaining why. The tl;dr; is that I have no idea
why this is necessary, but it gets --test to work on windows which is something,
right?
Alex Crichton [Tue, 5 Aug 2014 22:13:57 +0000 (15:13 -0700)]
syntax: Handle \r\n in byte string literals
This ended up passing through the lexer but dying later on in parsing when it
wasn't handled. The strategy taken was to copy the `str_lit` funciton, but adapt
it for bytes.
bors [Tue, 5 Aug 2014 17:21:23 +0000 (17:21 +0000)]
auto merge of #15709 : hirschenberger/rust/issue-14269, r=cmr
Fixes missing overflow lint for i64 #14269
The `type_overflow` lint, doesn't catch the overflow for `i64` because the overflow happens earlier in the parse phase when the `u64` as biggest possible int gets casted to `i64` , without checking the for
overflows.
We can't lint in the parse phase, so we emit a compiler error, as we do for overflowing `u64`
Perhaps a consistent behaviour would be to emit a parse error for *all* overflowing integer types.
bors [Tue, 5 Aug 2014 08:06:25 +0000 (08:06 +0000)]
auto merge of #16216 : omasanori/rust/nfkc, r=brson
The reference manual said that code is interpreted as UTF-8 text and a implementation will normalize it to NFKC. However, rustc doesn't do any normalization now.
We may want to do any normalization for symbols, but normalizing whole text seems harmful because doing so loses some sort of information even if we choose a non-K variant of normalization.
I'd suggest removing "normalized to Unicode normalization form NFKC" phrase for the present so that the manual represents the current state properly. When we address the problem (with a RFC?), then the manual should be updated.
The `type_overflow` lint, doesn't catch the overflow for `i64` because
the overflow happens earlier in the parse phase when the `u64` as biggest
possible int gets casted to `i64` , without checking the for overflows.
We can't lint in the parse phase, so a refactoring of the `LitInt` type
was necessary.
The types `LitInt`, `LitUint` and `LitIntUnsuffixed` where merged to one
type `LitInt` which stores it's value as `u64`. An additional parameter was
added which indicate the signedness of the type and the sign of the value.
Implement unwinding for Win64.
The original trick used to trigger unwinds would not work with GCC's implementation of SEH, so I had to invent a new one: rust_try now consists of two routines: the outer one, whose handler triggers unwinds, and the inner one, that stops unwinds by having a landing pad that swallows exceptions and passes them on to the outer routine via a normal return.
Ensure that Registers struct is 16-byte aligned on x86_64.
This is important when building with --disable-jemalloc: unlike jemalloc, msvcrt does not align on 16 bytes unless asked to.
Aaron Turon [Mon, 4 Aug 2014 22:42:36 +0000 (15:42 -0700)]
stabilize atomics (now atomic)
This commit stabilizes the `std::sync::atomics` module, renaming it to
`std::sync::atomic` to match library precedent elsewhere, and tightening
up behavior around incorrect memory ordering annotations.
The vast majority of the module is now `stable`. However, the
`AtomicOption` type has been deprecated, since it is essentially unused
and is not truly a primitive atomic type. It will eventually be replaced
by a higher-level abstraction like MVars.
bors [Mon, 4 Aug 2014 22:21:25 +0000 (22:21 +0000)]
auto merge of #16110 : alexcrichton/rust/issue-15460, r=brson
As discovered in #15460, a particular #[link(kind = "static", ...)] line is not
actually guaranteed to link the library at all. The reason for this is that if
the external library doesn't have any referenced symbols in the object generated
by rustc, the entire library is dropped by the linker.
For dynamic native libraries, this is solved by passing -lfoo for all downstream
compilations unconditionally. For static libraries in rlibs this is solved
because the entire archive is bundled in the rlib. The only situation in which
this was a problem was when a static native library was linked to a rust dynamic
library.
This commit brings the behavior of dylibs in line with rlibs by passing the
--whole-archive flag to the linker when linking native libraries. On OSX, this
uses the -force_load flag. This flag ensures that the entire archive is
considered candidate for being linked into the final dynamic library.
This is a breaking change because if any static library is included twice in the
same compilation unit then the linker will start emitting errors about duplicate
definitions now. The fix for this would involve only statically linking to a
library once.
Andrew Poelstra [Mon, 4 Aug 2014 16:46:15 +0000 (09:46 -0700)]
Change everything returning `libc::sockaddr_storage` to use an &mut out-ptr instead
The BSD socket code does some cast tricks with the `libc::sockaddr*`
structs, which causes useful data to be stored in struct padding.
Since Load/Store instructions do not copy struct padding, this makes
these structures dangerous to pass or return by value.
In particular, https://github.com/rust-lang/rust/issues/15763 changes
return semantics so that a Load instruction is used, breaking the TCP
code. Once this PR is merged, that one should merge without error.
Alex Crichton [Wed, 30 Jul 2014 14:44:20 +0000 (07:44 -0700)]
rustc: Link entire archives of native libraries
As discovered in #15460, a particular #[link(kind = "static", ...)] line is not
actually guaranteed to link the library at all. The reason for this is that if
the external library doesn't have any referenced symbols in the object generated
by rustc, the entire library is dropped by the linker.
For dynamic native libraries, this is solved by passing -lfoo for all downstream
compilations unconditionally. For static libraries in rlibs this is solved
because the entire archive is bundled in the rlib. The only situation in which
this was a problem was when a static native library was linked to a rust dynamic
library.
This commit brings the behavior of dylibs in line with rlibs by passing the
--whole-archive flag to the linker when linking native libraries. On OSX, this
uses the -force_load flag. This flag ensures that the entire archive is
considered candidate for being linked into the final dynamic library.
This is a breaking change because if any static library is included twice in the
same compilation unit then the linker will start emitting errors about duplicate
definitions now. The fix for this would involve only statically linking to a
library once.
bors [Mon, 4 Aug 2014 17:06:19 +0000 (17:06 +0000)]
auto merge of #15986 : Florob/rust/nfKc-new, r=alexcrichton
This adds a new `Recompositions` iterator, which performs canonical composition on the result of the `Decompositions` iterator (which is canonical or compatibility decomposition). In effect this implements Unicode normalization forms C and KC.
bors [Mon, 4 Aug 2014 07:01:10 +0000 (07:01 +0000)]
auto merge of #16213 : huonw/rust/more-token-numbers, r=pnkfelix
Using the Show impl for Names created global symbols with names like
`"str\"str\"(1027)"`. This adjusts strings, binaries and vtables to
avoid using that impl.
Huon Wilson [Sun, 3 Aug 2014 07:00:13 +0000 (17:00 +1000)]
rustc: use Name numbers rather than the Show impl for constants.
Using the Show impl for Names created global symbols with names like
`"str\"str\"(1027)"`. This adjusts strings, binaries and vtables to
avoid using that impl.
bors [Mon, 4 Aug 2014 01:31:09 +0000 (01:31 +0000)]
auto merge of #16139 : michaelwoerister/rust/rlib-bc-versioning, r=alexcrichton
Before this commit, the LLVM IR of exported items was simply zip-compressed and stored as an object file inside rlib archives. This commit adds a header to this "object" containing a file identifier and a format version number so the compiler can deal with changes in the way bytecode objects are stored within rlibs.
While updating the format of bytecode objects, this commit also worksaround a problem in LLDB which could not handle odd-sized objects within archives before mid-2014.
bors [Sun, 3 Aug 2014 23:46:10 +0000 (23:46 +0000)]
auto merge of #16215 : cakebaker/rust/remove_bin_section_from_toml, r=alexcrichton
According to the [source code](https://github.com/rust-lang/cargo/blob/master/src/cargo/ops/cargo_new.rs#L31) <code>cargo new</code> doesn't generate a <code>[[bin]]</code> section in the <code>Cargo.toml</code>, hence removing it from the example.
Use a versioning scheme for bytecode objects in rlibs.
Before this commit, the LLVM IR of exported items was simply zip-compressed and stored as an object file inside rlib archives. This commit adds a header to this "object" containing a file identifier and a format version number so the compiler can deal with changes in the way bytecode objects are stored within rlibs.
While updating the format of bytecode objects, this commit also worksaround a problem in LLDB which could not handle odd-sized objects within archives before mid-2014.
bors [Sun, 3 Aug 2014 17:01:06 +0000 (17:01 +0000)]
auto merge of #16209 : tomjakubowski/rust/rustdoc-html-changes, r=alexcrichton
This PR introduces a couple of minor changes to the rustdoc html templates:
1. The `<meta name="generator" content="rustdoc">` tag now appears in API documentation as well.
2. Adds a `rustdoc` class to the top-level `<body>` tag on all HTML pages.
The second point is a nice-to-have for those who would like to apply a user stylesheet to Rust documentation regardless of where it is hosted. Easier use of user stylesheets may alleviate much of the bikeshedding of personal taste on the rustdoc styles.
OGINO Masanori [Sun, 3 Aug 2014 14:41:05 +0000 (23:41 +0900)]
Remove the "NFKC clause" in the reference manual.
The reference manual said that code is interpreted as UTF-8 text and a
implementation will normalize it to NFKC. However, rustc doesn't do
any normalization now.
We may want to do any normalization for symbols, but normalizing whole
text seems harmful because doing so loses some sort of information even
if we choose a non-K variant of normalization.
I'd suggest removing "normalized to Unicode normalization form NFKC"
phrase for the present so that the manual represents the current state
properly. When we address the problem (with a RFC?), then the manual
should be updated.
bors [Sun, 3 Aug 2014 03:06:12 +0000 (03:06 +0000)]
auto merge of #16191 : DaGenix/rust/fix-aligned-access, r=alexcrichton
When I originally wrote the read_u32v_be() and write_u32_be() functions, I didn't consider memory alignment requirements of various architectures. Unfortunately, the current implementations may result in unaligned reads and writes. This doesn't impact x86 / x86_64, but it can cause a compiler crash on ARM. This pull requests rewrites those functions to make sure that all memory access is always correctly aligned.
This fix is a little bit academic - due to the way that LLVM aligns the structures that are passed as arguments to these functions, I believe that the end result is that all memory access happens to be aligned anyway. However, there is nothing in that code that actually enforces that, at least not explicitly. The new implementations are definitely slower than the existing ones. However, I don't believe that these functions are all that significant when looking at the overall performance of the compiler. I think getting rid of some unsafe code and removing a potential portability landmine justifies a very slight decrease in raw performance.
projects / rust.git / log