Auto merge of #27153 - alexcrichton:flaky-tests, r=brson
This commit ensures that the rustc thread does not leak a panic message whenever
a call to `fatal` happens. This already happens for the main rustc thread as
part of the `rustc_driver::monitor` function, but the compiler also spawns
threads for other operations like `-C codegen-units`, and sometimes errors are
emitted on these threads as well. To ensure that there's a consistent
error-handling experience across threads this unifies these two to never print
the panic message in the case of a normal and expected fatal error.
This should also fix the flaky `asm-src-loc-codegen-units.rs` test as the output
is sometimes garbled if diagnostics are printed while the panic message is also
being printed.
Auto merge of #27139 - pnkfelix:allow-disable-debuginfo, r=dotdash
fix `configure`: allow both `--enable-debug` and `--disable-debuginfo` in one invocation.
This is my very local fix to allow one to be able to (1.) build `rustc` and (2.) run `make check` with internal debug-mode *assertions* turned on in the presence of bugs like #26447 and #26484 (both of which are solely caused by debuginfo and thus can be sidestepped via `--disable-debuginfo`).
This partially addresses #24416 (namely, it addresses the papercut outlined in the description of that ticket). But there are other issues mentioned in the comment thread that are not addressed here, so they should be separately addressed before closing that ticket, or separate bugs should be opened for them.
Auto merge of #27103 - wthrowe:doc_format, r=alexcrichton
This fixes a couple of bugs visible on https://doc.rust-lang.org/nightly/std/marker/trait.Sync.html . For example:
* `impl<T> Sync for *const T` should read `impl<T> !Sync for *const T`
* `impl<T> !Sync for Weak<T>` should read `impl<T> !Sync for Weak<T> where T: ?Sized`
This does change a struct in librustdoc and it seems that almost everything there is marked public, so if librustdoc has stability guarantees that could be a problem. If it is, I'll find a way to rework the change to avoid modifying public structures.
Auto merge of #27129 - arthurprs:debug_atomic, r=alexcrichton
I'm being constantly bitten by the lack of this implementation.
I'm unsure if there's a reason to avoid these implementations though.
Since we have a "lossy" implementation for both Mutex and RWLock (RWLock {{ locked }}) I don't think there's a big reason for not having a Debug implementation for the atomic types, even if the user can't specify the ordering.
Auto merge of #27056 - Eljay:doc-comments, r=nikomatsakis
Fixes #23812 by stripping the decoration when desugaring macro doc comments into #[doc] attributes, and detects whether the attribute should be inner or outer style and outputs the appropriate token tree.
Auto merge of #27064 - alexcrichton:into-raw-os, r=brson
This commit is an implementation of [RFC 1174][rfc] which adds three new traits
to the standard library:
* `IntoRawFd` - implemented on Unix for all I/O types (files, sockets, etc)
* `IntoRawHandle` - implemented on Windows for files, processes, etc
* `IntoRawSocket` - implemented on Windows for networking types
Alex Crichton [Mon, 20 Jul 2015 16:23:31 +0000 (09:23 -0700)]
syntax: Suppress panic message on `fatal`
This commit ensures that the rustc thread does not leak a panic message whenever
a call to `fatal` happens. This already happens for the main rustc thread as
part of the `rustc_driver::monitor` function, but the compiler also spawns
threads for other operations like `-C codegen-units`, and sometimes errors are
emitted on these threads as well. To ensure that there's a consistent
error-handling experience across threads this unifies these two to never print
the panic message in the case of a normal and expected fatal error.
This should also fix the flaky `asm-src-loc-codegen-units.rs` test as the output
is sometimes garbled if diagnostics are printed while the panic message is also
being printed.
Alex Crichton [Thu, 16 Jul 2015 06:31:24 +0000 (23:31 -0700)]
std: Add IntoRaw{Fd,Handle,Socket} traits
This commit is an implementation of [RFC 1174][rfc] which adds three new traits
to the standard library:
* `IntoRawFd` - implemented on Unix for all I/O types (files, sockets, etc)
* `IntoRawHandle` - implemented on Windows for files, processes, etc
* `IntoRawSocket` - implemented on Windows for networking types
Auto merge of #27110 - arthurprs:optintstr, r=Gankro
I wrote a reasonably optimized version for both functions. Further optimizations are possible but I tried to keep the code size small (which I think is important), it's a road of diminished gains.
The repository used for testing/benchmarks is https://github.com/arthurprs/rust-optimized-inttostr
Benchmarks are ran for 3 different distributions, bellow are string length histograms for the u32 type
Tested processors are
* x64 laptop (i7-2670QM)
* x32 server (Digital Ocean E5-2630L-v2)
### Display
It uses a small look up table (200 bytes) and decode up to 4 characters at a time. I also took special precautions to reduce 64bit arithmetic on 32bit architectures and the gains are huge in these cases.
Overall, on modern 64bit CPUs it's pretty much the same speed as the stdlib implementation for very small numbers (0..99), but pulls ahead as the length of the decimal increases. On slight older CPUs (w/ worse ALUs) or 32bit architectures it's pretty much always faster.
x64 benchmarks
```
test bench::display_h_new_u08 ... bench: 71,041 ns/iter (+/- 2,894)
test bench::display_h_new_u16 ... bench: 378,255 ns/iter (+/- 36,547)
test bench::display_h_new_u32 ... bench: 4,232,483 ns/iter (+/- 509,661)
test bench::display_h_new_u64 ... bench: 5,166,740 ns/iter (+/- 421,124)
test bench::display_h_stdlib_u08 ... bench: 73,536 ns/iter (+/- 5,287)
test bench::display_h_stdlib_u16 ... bench: 451,443 ns/iter (+/- 16,879)
test bench::display_h_stdlib_u32 ... bench: 5,551,070 ns/iter (+/- 518,151)
test bench::display_h_stdlib_u64 ... bench: 8,624,374 ns/iter (+/- 643,701)
test bench::display_l_new_u08 ... bench: 71,547 ns/iter (+/- 504)
test bench::display_l_new_u16 ... bench: 399,727 ns/iter (+/- 28,030)
test bench::display_l_new_u32 ... bench: 4,365,303 ns/iter (+/- 414,414)
test bench::display_l_new_u64 ... bench: 5,302,382 ns/iter (+/- 292,324)
test bench::display_l_stdlib_u08 ... bench: 75,445 ns/iter (+/- 2,487)
test bench::display_l_stdlib_u16 ... bench: 444,313 ns/iter (+/- 16,203)
test bench::display_l_stdlib_u32 ... bench: 5,761,801 ns/iter (+/- 387,186)
test bench::display_l_stdlib_u64 ... bench: 8,790,365 ns/iter (+/- 614,846)
test bench::display_m_new_u08 ... bench: 71,820 ns/iter (+/- 2,956)
test bench::display_m_new_u16 ... bench: 399,649 ns/iter (+/- 20,643)
test bench::display_m_new_u32 ... bench: 4,355,561 ns/iter (+/- 179,189)
test bench::display_m_new_u64 ... bench: 5,070,594 ns/iter (+/- 341,950)
test bench::display_m_stdlib_u08 ... bench: 74,900 ns/iter (+/- 1,909)
test bench::display_m_stdlib_u16 ... bench: 448,788 ns/iter (+/- 20,791)
test bench::display_m_stdlib_u32 ... bench: 5,717,939 ns/iter (+/- 316,824)
test bench::display_m_stdlib_u64 ... bench: 8,787,160 ns/iter (+/- 482,864)
```
x86 benchmarks
```
test bench::display_h_new_u08 ... bench: 94,246 ns/iter (+/- 34,872)
test bench::display_h_new_u16 ... bench: 533,805 ns/iter (+/- 22,499)
test bench::display_h_new_u32 ... bench: 6,127,747 ns/iter (+/- 2,192,789)
test bench::display_h_new_u64 ... bench: 14,994,203 ns/iter (+/- 1,609,345)
test bench::display_h_stdlib_u08 ... bench: 107,233 ns/iter (+/- 8,571)
test bench::display_h_stdlib_u16 ... bench: 631,186 ns/iter (+/- 11,332)
test bench::display_h_stdlib_u32 ... bench: 7,696,344 ns/iter (+/- 957,917)
test bench::display_h_stdlib_u64 ... bench: 45,677,401 ns/iter (+/- 4,991,344)
test bench::display_l_new_u08 ... bench: 95,855 ns/iter (+/- 27,735)
test bench::display_l_new_u16 ... bench: 532,084 ns/iter (+/- 40,479)
test bench::display_l_new_u32 ... bench: 5,973,953 ns/iter (+/- 211,676)
test bench::display_l_new_u64 ... bench: 14,773,064 ns/iter (+/- 1,276,579)
test bench::display_l_stdlib_u08 ... bench: 106,350 ns/iter (+/- 63,963)
test bench::display_l_stdlib_u16 ... bench: 637,746 ns/iter (+/- 101,005)
test bench::display_l_stdlib_u32 ... bench: 7,740,640 ns/iter (+/- 848,478)
test bench::display_l_stdlib_u64 ... bench: 44,846,932 ns/iter (+/- 4,514,694)
test bench::display_m_new_u08 ... bench: 94,549 ns/iter (+/- 13,029)
test bench::display_m_new_u16 ... bench: 546,030 ns/iter (+/- 35,804)
test bench::display_m_new_u32 ... bench: 5,983,924 ns/iter (+/- 1,180,559)
test bench::display_m_new_u64 ... bench: 14,817,873 ns/iter (+/- 2,271,464)
test bench::display_m_stdlib_u08 ... bench: 107,806 ns/iter (+/- 8,805)
test bench::display_m_stdlib_u16 ... bench: 630,714 ns/iter (+/- 6,586)
test bench::display_m_stdlib_u32 ... bench: 7,784,210 ns/iter (+/- 358,601)
test bench::display_m_stdlib_u64 ... bench: 46,223,927 ns/iter (+/- 6,553,176)
```
### from_str_radix (FromStr)
All valid digits are ascii so I modified the function to use the underlining bytes instead and simplified the match to avoid wasting cycles.
x64 benchmarks
```
test bench::from_str_h_new_u08 ... bench: 28,153 ns/iter (+/- 624)
test bench::from_str_h_new_u16 ... bench: 223,513 ns/iter (+/- 11,554)
test bench::from_str_h_new_u32 ... bench: 3,098,935 ns/iter (+/- 231,022)
test bench::from_str_h_new_u64 ... bench: 5,009,900 ns/iter (+/- 341,961)
test bench::from_str_h_stdlib_u08 ... bench: 34,033 ns/iter (+/- 2,068)
test bench::from_str_h_stdlib_u16 ... bench: 248,785 ns/iter (+/- 14,208)
test bench::from_str_h_stdlib_u32 ... bench: 4,150,536 ns/iter (+/- 266,070)
test bench::from_str_h_stdlib_u64 ... bench: 6,817,997 ns/iter (+/- 449,838)
test bench::from_str_l_new_u08 ... bench: 27,552 ns/iter (+/- 1,500)
test bench::from_str_l_new_u16 ... bench: 234,360 ns/iter (+/- 13,144)
test bench::from_str_l_new_u32 ... bench: 3,140,261 ns/iter (+/- 248,175)
test bench::from_str_l_new_u64 ... bench: 5,176,583 ns/iter (+/- 350,416)
test bench::from_str_l_stdlib_u08 ... bench: 35,060 ns/iter (+/- 2,154)
test bench::from_str_l_stdlib_u16 ... bench: 252,135 ns/iter (+/- 23,461)
test bench::from_str_l_stdlib_u32 ... bench: 4,154,599 ns/iter (+/- 369,606)
test bench::from_str_l_stdlib_u64 ... bench: 6,892,767 ns/iter (+/- 213,030)
test bench::from_str_m_new_u08 ... bench: 28,252 ns/iter (+/- 1,384)
test bench::from_str_m_new_u16 ... bench: 231,051 ns/iter (+/- 16,540)
test bench::from_str_m_new_u32 ... bench: 3,166,504 ns/iter (+/- 134,418)
test bench::from_str_m_new_u64 ... bench: 5,103,195 ns/iter (+/- 218,912)
test bench::from_str_m_stdlib_u08 ... bench: 35,012 ns/iter (+/- 2,735)
test bench::from_str_m_stdlib_u16 ... bench: 250,967 ns/iter (+/- 14,708)
test bench::from_str_m_stdlib_u32 ... bench: 4,101,845 ns/iter (+/- 205,802)
test bench::from_str_m_stdlib_u64 ... bench: 6,823,001 ns/iter (+/- 267,215)
```
x86 benchmarks
```
test bench::from_str_h_new_u08 ... bench: 23,682 ns/iter (+/- 3,590)
test bench::from_str_h_new_u16 ... bench: 190,916 ns/iter (+/- 29,688)
test bench::from_str_h_new_u32 ... bench: 2,649,952 ns/iter (+/- 308,576)
test bench::from_str_h_new_u64 ... bench: 23,458,434 ns/iter (+/- 2,327,427)
test bench::from_str_h_stdlib_u08 ... bench: 45,551 ns/iter (+/- 6,968)
test bench::from_str_h_stdlib_u16 ... bench: 313,739 ns/iter (+/- 17,175)
test bench::from_str_h_stdlib_u32 ... bench: 4,615,669 ns/iter (+/- 470,766)
test bench::from_str_h_stdlib_u64 ... bench: 30,589,482 ns/iter (+/- 2,278,996)
test bench::from_str_l_new_u08 ... bench: 23,763 ns/iter (+/- 5,545)
test bench::from_str_l_new_u16 ... bench: 185,472 ns/iter (+/- 33,097)
test bench::from_str_l_new_u32 ... bench: 2,691,307 ns/iter (+/- 473,886)
test bench::from_str_l_new_u64 ... bench: 22,952,593 ns/iter (+/- 1,963,742)
test bench::from_str_l_stdlib_u08 ... bench: 45,285 ns/iter (+/- 16,337)
test bench::from_str_l_stdlib_u16 ... bench: 313,624 ns/iter (+/- 6,643)
test bench::from_str_l_stdlib_u32 ... bench: 4,595,679 ns/iter (+/- 1,876,361)
test bench::from_str_l_stdlib_u64 ... bench: 30,434,683 ns/iter (+/- 1,901,996)
test bench::from_str_m_new_u08 ... bench: 23,812 ns/iter (+/- 1,505)
test bench::from_str_m_new_u16 ... bench: 185,553 ns/iter (+/- 19,788)
test bench::from_str_m_new_u32 ... bench: 2,614,920 ns/iter (+/- 66,230)
test bench::from_str_m_new_u64 ... bench: 23,241,778 ns/iter (+/- 3,474,077)
test bench::from_str_m_stdlib_u08 ... bench: 45,634 ns/iter (+/- 1,436)
test bench::from_str_m_stdlib_u16 ... bench: 316,479 ns/iter (+/- 21,212)
test bench::from_str_m_stdlib_u32 ... bench: 4,609,147 ns/iter (+/- 487,068)
test bench::from_str_m_stdlib_u64 ... bench: 30,165,173 ns/iter (+/- 1,601,830)
```
Auto merge of #27101 - steveklabnik:doc_no_mutability_root, r=Gankro
And some other outdated language. @echochamber came asking about these docs
on IRC today, and they're a bit weird. I've updated them to be less ambiguous
and use contemporary terminology.
Auto merge of #27099 - AlisdairO:diagnostics3, r=Manishearth
Per the title. I've linked to the reference at http://doc.rust-lang.org/reference.html#type-parameters-1, but I'm not sure that's such a good link - but there doesn't seem to be a great deal of explanation elsewhere in the reference either...
Björn Steinbrink [Tue, 14 Jul 2015 17:03:13 +0000 (19:03 +0200)]
Create correct debuginfo for closure function signatures
Internally, the arguments passed to the closure are represented by a
tuple, but the actual function takes them as individual arguments, so we
have to untuple the arguments before creating the debuginfo.
Björn Steinbrink [Mon, 13 Jul 2015 19:48:07 +0000 (21:48 +0200)]
Properly create debug info for functions
We're currently using the actual function type as the return type when
creating the debug info for a function, so we're actually creating
debug info for a function that takes the same parameters, and returns
the actual function type, which is completely wrong.
William Throwe [Sat, 18 Jul 2015 06:02:57 +0000 (02:02 -0400)]
Fix rustdoc formatting of impls
Some cases displayed negative impls as positive, and some were missing
where clauses. This factors all the impl formatting into one
function so the different cases can't get out of sync again.
Auto merge of #27085 - Ryman:gh17546, r=alexcrichton
This also changes how variant values are printed in errors, they are no
longer printed in their parent scope. As far as I can tell, this is
leftover from pre-namespacing of enums.
Auto merge of #26955 - Gankro:raw-vec, r=bluss,alexcrichton
Per the top level comment:
A low-level utility for more ergonomically allocating, reallocating, and deallocating a
a buffer of memory on the heap without having to worry about all the corner cases
involved. This type is excellent for building your own data structures like Vec and VecDeque.
In particular:
* Produces heap::EMPTY on zero-sized types
* Produces heap::EMPTY on zero-length allocations
* Catches all overflows in capacity computations (promotes them to "capacity overflow" panics)
* Guards against 32-bit systems allocating more than isize::MAX bytes
* Guards against overflowing your length
* Aborts on OOM
* Avoids freeing heap::EMPTY
* Contains a ptr::Unique and thus endows the user with all related benefits
This type does not in anyway inspect the memory that it manages. When dropped it *will*
free its memory, but it *won't* try to Drop its contents. It is up to the user of RawVec
to handle the actual things *stored* inside of a RawVec.
Note that a RawVec always forces its capacity to be usize::MAX for zero-sized types.
This enables you to use capacity growing logic catch the overflows in your length
that might occur with zero-sized types.
However this means that you need to be careful when roundtripping this type
with a `Box<[T]>`: `cap()` won't yield the len. However `with_capacity`,
`shrink_to_fit`, and `from_box` will actually set RawVec's private capacity
field. This allows zero-sized types to not be special-cased by consumers of
this type.
Steve Klabnik [Fri, 17 Jul 2015 22:50:42 +0000 (18:50 -0400)]
Remove confusing 'mutability root' term
And some other outdated language. @echochamber came asking about these docs
on IRC today, and they're a bit weird. I've updated them to be less ambiguous
and use contemporary terminology.
Rollup merge of #26777 - barosl:macro-doc-escapes, r=pnkfelix
Escape sequences in documentation comments must not be parsed as a normal string when expanding a macro, otherwise some innocent but invalid-escape-sequence-looking comments will trigger an ICE.
Although this commit replaces normal string literals with raw string literals in macro expansion, this shouldn't be much a problem considering documentation comments are converted into attributes before being passed to a macro anyways.
Auto merge of #27045 - nikomatsakis:better-object-defaults-error, r=pnkfelix
Transition to the new object lifetime defaults, replacing the old defaults completely.
r? @pnkfelix
This is a [breaking-change] as specified by [RFC 1156][1156] (though all cases that would break should have been receiving warnings starting in Rust 1.2). Types like `&'a Box<Trait>` (or `&'a Rc<Trait>`, etc) will change from being interpreted as `&'a Box<Trait+'a>` to `&'a Box<Trait+'static>`. To restore the old behavior, write the `+'a` explicitly. For example, the function:
Auto merge of #27076 - alexcrichton:update-llvm, r=brson
LLVM has recently created their 3.7 release branch, and this PR updates us to that point. This should hopefully mean that we're basically compatible with the upcoming 3.7 release. Additionally, there are a number of goodies on this branch.
* This contains a fix for https://llvm.org/bugs/show_bug.cgi?id=23957
which should help us bootstrap farther on 32-bit MSVC targets.
* There is better support for writing multiple flavors of archives, allowing us
to use the built-in LLVM support instead of the system `ar` on all current
platforms of the compiler.
* This LLVM has SafeStack support
* An [optimization patch](https://github.com/rust-lang/llvm/commit/7cf5e26e18f7d2d8db09c83c76dd727535f281ab) by @pcwalton is included.
* A number of other minor test fixes here and there.
Due to problems dealing with the data layout we pass to LLVM, this PR also takes the time to clean up how we specific this. We no longer specify a data layout to LLVM by default and instead take the default for the target from LLVM to pass to the module that we're building. This should be more robust going into the future, and I'm also not sure we know what any of these arcane strings are any more...
Kevin Butler [Fri, 17 Jul 2015 14:16:22 +0000 (15:16 +0100)]
Improve error message for variant values used as types
This also changes how variant values are printed in errors, they are no
longer printed in their parent scope. As far as I can tell, this is
leftover from pre-namespacing of enums.