Auto merge of #27388 - alexcrichton:remove-curious-inner, r=brson
This isn't actually necessary any more with the advent of `$crate` and changes
in the compiler to expand macros to `::core::$foo` in the context of a
`#![no_std]` crate.
The libcore inner module was also trimmed down a bit to the bare bones.
Auto merge of #27386 - chris-morgan:ctags-stuff-update, r=alexcrichton
As there’s no C++ runtime any more there’s really no point in having anything but Rust tags being made.
I’ve also taken the liberty of excluding the compiler parts of this in the `librust%,,` pattern substitution. Whether or not this is “correct” will depend on whether you want tags for the compiler or for general use. For myself, I want it for general use.
I’m not sure how much people use the tags files anyway. I definitely do, but with Racer existing the tags files aren’t quite so necessary.
Auto merge of #27371 - Gankro:str-clone, r=alexcrichton
This is a minor [breaking-change], as it changes what
`boxed_str.to_owned()` does (previously it would deref to `&str` and
call `to_owned` on that to get a `String`). However `Box<str>` is such an
exceptionally rare type that this is not expected to be a serious
concern. Also a `Box<str>` can be freely converted to a `String` to
obtain the previous result anyway.
Auto merge of #27052 - wthrowe:atomic_send, r=Gankro
I think this was just missed when `Send` and `Sync` were redone, since it seems odd to not be able to use things like `Arc<AtomicPtr>`. If it was intentional feel free to just close this.
I used another test as a template for writing mine, so I hope I got all the headers and stuff right.
This is a minor [breaking-change], as it changes what
`boxed_str.to_owned()` does (previously it would deref to `&str` and
call `to_owned` on that to get a `String`). However `Box<str>` is such an
exceptionally rare type that this is not expected to be a serious
concern. Also a `Box<str>` can be freely converted to a `String` to
obtain the previous behaviour anyway.
Auto merge of #27032 - Gankro:tarpl, r=aturon,acrichto,arielb,pnkfelix,nrc,nmatsakis,huonw
I've been baking this out of tree for long enough. This is currently about ~2/5ths the size of TRPL. Time to get it in tree so it can be more widely maintained and scrutinized. I've preserved the whole gruesome history including various rewrites. I can definitely squash these a fair amount if desired. Some random people submitted minor fixes though, so they're mixed in.
Edit: forgot to link to rendered http://cglab.ca/~abeinges/blah/turpl/_book/
Edit2:
To streamline the review process, I'm going to break this into sections that need official "domain expert" approval:
# Summary
* [ ] references.md -- very important, needs work
* [x] Meet Safe and Unsafe: reviewed by @aturon
* [x] Data Layout: reviewed by @arielb1
* [x] Ownership: reviewed by @aturon ( and sorta @nikomatsakis ) -- significantly updated, may need re-r
* [x] Coversions: reviewed by @nrc
* [x] Uninitialized Memory: reviewed by @pnkfelix
* [x] Ownership-Oriented Resource Management: reviewed by @aturon
* [x] Unwinding: reviewed by @alexcrichton
* [x] Concurrency: reviewed by @aturon
* [x] Implementing Vec: r? @huonw
Alex Crichton [Wed, 29 Jul 2015 21:14:01 +0000 (14:14 -0700)]
std: Remove the curious inner module
This isn't actually necessary any more with the advent of `$crate` and changes
in the compiler to expand macros to `::core::$foo` in the context of a
`#![no_std]` crate.
The libcore inner module was also trimmed down a bit to the bare bones.
Chris Morgan [Wed, 29 Jul 2015 20:35:42 +0000 (06:35 +1000)]
Update the ctags rules and targets.
As there’s no C++ runtime any more there’s really no point in having
anything but Rust tags being made.
I’ve also taken the liberty of excluding the compiler parts of this in
the `librust%,,` pattern substitution. Whether or not this is “correct”
will depend on whether you want tags for the compiler or for general
use. For myself, I want it for general use.
I’m not sure how much people use the tags files anyway. I definitely do,
but with Racer existing the tags files aren’t quite so necessary.
Rollup merge of #27373 - alexcrichton:fix-wait-timeout-ms, r=brson
The API we're calling requires us to pass an absolute point in time as an
argument (`pthread_cond_timedwait`) so we call `gettimeofday` ahead of time to
then add the specified duration to. Unfortuantely the current "add the duration"
logic forgot to take into account the current time's sub-second precision (e.g.
the `tv_usec` field was ignored), causing sub-second duration waits to return
spuriously.
Auto merge of #27368 - alexcrichton:deprecate-net-methods, r=aturon
These methods are all covered by [RFC 1158] and are currently all available on
stable Rust via the [`net2` crate][net2] on crates.io. This commit does not
touch the timeout related functions as they're still waiting on `Duration` which
is unstable anyway, so punting in favor of the `net2` crate wouldn't buy much.
Alex Crichton [Wed, 29 Jul 2015 04:13:02 +0000 (21:13 -0700)]
std: Fix sub-second Condvar::wait_timeout_ms
The API we're calling requires us to pass an absolute point in time as an
argument (`pthread_cond_timedwait`) so we call `gettimeofday` ahead of time to
then add the specified duration to. Unfortuantely the current "add the duration"
logic forgot to take into account the current time's sub-second precision (e.g.
the `tv_usec` field was ignored), causing sub-second duration waits to return
spuriously.
Auto merge of #27346 - dotdash:closure_dbg, r=michaelwoerister
Closure variables represent the closure environment, not the closure
function, so the identifier used to ensure that the debuginfo is unique
for each kind of closure needs to be based on the closure upvars and not
the function signature.
Steve Klabnik [Wed, 29 Jul 2015 14:30:37 +0000 (10:30 -0400)]
Rollup merge of #27379 - jeehoonkang:master, r=steveklabnik
As described in the module documentation, the memory orderings in Rust
are the same with that of LLVM. However, the documentation for the
memory orderings enum says the memory orderings are the same of that of
C++. Note that they differ in that C++'s support the consume reads,
while LLVM's does not. Hence this commit fixes the bug in the
documentation for the enum.
Steve Klabnik [Wed, 29 Jul 2015 14:30:36 +0000 (10:30 -0400)]
Rollup merge of #27375 - niconii:vec-docs, r=Gankro
Noticed that syntax like `vec![0; 5]` is never mentioned in `Vec<T>`'s docs, nor used in any of its methods' docs, so I figured I should add a mention of it. Also noticed `vec!(1, 2)` being used in one spot while I was at it, so I fixed that as well for consistency's sake.
Steve Klabnik [Wed, 29 Jul 2015 14:30:35 +0000 (10:30 -0400)]
Rollup merge of #27345 - killercup:patch-15, r=alexcrichton
The first paragraph of the docs of the Cursor struct ([src](https://github.com/rust-lang/rust/blob/ff6c6ce917bd6af9c5d9315708ae6be3ba0b7e91/src/libstd/io/cursor.rs#L18-L21)) contains a Markdown link. In listings (like <http://doc.rust-lang.org/nightly/std/io/>), this won't get rendered:
The hotfix would be to change the link by reference:
```rust
/// A `Cursor` wraps another type and provides it with a [`Seek`][seek]
/// implementation.
///
/// [seek]: trait.Seek.html
```
to a direct link:
```rust
/// A `Cursor` wraps another type and provides it with a
/// [`Seek`](trait.Seek.html) implementation.
```
_I have not tested this as I don't have access to a machine for compiling Rust right now._
(This seems to be a more general issue, but I think I have seen this mentioned before. This PR is just to hotfix on particular occurrence. Rustdoc seems to only read the first paragraph of a doc string for the description in index pages, and _after that_ convert Markdown to HTML.)
Steve Klabnik [Wed, 29 Jul 2015 14:30:34 +0000 (10:30 -0400)]
Rollup merge of #27326 - steveklabnik:doc_show_use, r=Gankro
In spirit with https://internals.rust-lang.org/t/should-we-keep-including-obvious-imports-in-code-examples/2217, show the feature flags we're using in examples.
Steve Klabnik [Wed, 29 Jul 2015 14:30:33 +0000 (10:30 -0400)]
Rollup merge of #27313 - nagisa:illegal-to-invalid, r=pnkfelix
Improves diagnostics in various locations, namely:
* A few error messages that orignally were a mix of an error message and suggestion how to fix it have been split up into two messages: an error and help/hint.
* Never report “illegal”. Fixes https://github.com/rust-lang/rust/issues/27288
Steve Klabnik [Wed, 29 Jul 2015 14:30:33 +0000 (10:30 -0400)]
Rollup merge of #27286 - lastorset:pub, r=steveklabnik
The reader could probably infer this from the current text, but for C++ programmers it's not obvious that struct fields don't automatically become public.
Jeehoon Kang [Wed, 29 Jul 2015 13:48:25 +0000 (22:48 +0900)]
Fix a documentation bug for memory orderings
As described in the module documentation, the memory orderings in Rust
are the same with that of LLVM. However, the documentation for the
memory orderings enum says the memory orderings are the same of that of
C++. Note that they differ in that C++'s support the consume reads,
while LLVM's does not. Hence this commit fixes the bug in the
documentation for the enum.
Auto merge of #27339 - alexcrichton:remove-old-rt, r=brson
These aren't really used for anything any more, so there doesn't seem to be much
reason to leave them around in the `rt` directory. There was some limiting of
threads spawned or tests when run under valgrind, but very little is run under
valgrind nowadays so there's also no real use keeping these around.
Auto merge of #27260 - alexcrichton:cap-lints, r=nrc
This commit is an implementation of [RFC 1193][rfc] which adds the ability to
the compiler to cap the lint level for the entire compilation session. This flag
will ensure that no lints will go above this level, and Cargo will primarily use
this flag passing `--cap-lints allow` to all upstream dependencies.
Alex Crichton [Fri, 24 Jul 2015 05:19:12 +0000 (22:19 -0700)]
rustc: Add a --cap-lints flag to the compiler
This commit is an implementation of [RFC 1193][rfc] which adds the ability to
the compiler to cap the lint level for the entire compilation session. This flag
will ensure that no lints will go above this level, and Cargo will primarily use
this flag passing `--cap-lints allow` to all upstream dependencies.
Auto merge of #26846 - P1start:print-maybe-styled-macro, r=pnkfelix
`EmitterWriter::print_maybe_styled` was basically always used with `format!`, so this macro makes some code cleaner. It should also remove some unnecessary allocations (most `print_maybe_styled` invocations allocated a `String` previously, whereas the new macro uses `write_fmt` to write the formatted string directly to the terminal).
This probably could have been part of #26838, but it’s too late now. It’s also rebased on #26838’s branch because otherwise pretty much all of the changes in this PR would conflict with the other PR’s changes.
Alex Crichton [Tue, 28 Jul 2015 23:03:29 +0000 (16:03 -0700)]
std: Deprecate extra TcpStream/UdpSocket methods
These methods are all covered by [RFC 1158] and are currently all available on
stable Rust via the [`net2` crate][net2] on crates.io. This commit does not
touch the timeout related functions as they're still waiting on `Duration` which
is unstable anyway, so punting in favor of the `net2` crate wouldn't buy much.
Auto merge of #27173 - mark-buer:split-android-ndks, r=alexcrichton
Allows a multi-Android-target Rust compiler to be built.
Without these (or similar) changes, only a single-Android-target Rust compiler is possible.
Please see https://internals.rust-lang.org/t/dual-target-android-rust-compiler/2382/3 for additional context.
Auto merge of #26173 - pnkfelix:fsk-trans-nzmove-take3, r=nikomatsakis
Add dropflag hints (stack-local booleans) for unfragmented paths in trans. Part of #5016.
Added code to maintain these hints at runtime, and to conditionalize drop-filling and calls to destructors.
In this early stage of my incremental implementation strategy, we are using hints, so we are always free to leave out a flag for a path -- then we just pass `None` as the dropflag hint in the corresponding schedule cleanup call. But, once a path has a hint, we must at least maintain it: i.e. if the hint exists, we must ensure it is never set to "moved" if the data in question might actually have been initialized. It remains sound to conservatively set the hint to "initialized" as long as the true drop-flag embedded in the value itself is up-to-date.
I hope the commit series has been broken up to be readable; most of the commits in the series should build (though I did not always check this).
----
Oh, I think this technically qualifies as a:
[breaking-change]
because it removes drop-filling in some cases where one could previously observe it. That should only affect `unsafe` code; no safe code should be able to inspect whether the drop-fill was present or not. For an example of code that needed to change to account for this, see commit a81c24ae0216ab47df59acd724f8a33124fb6d97 (a unit test of the `move_val_init` intrinsic). I have not encountered actual code that needed to be updated to account for the change, since this should only be skipping the drop-filling on *moved* values, not on dropped one, and so even types that use `unsafe_no_drop_flag` should be unchanged by this particular PR. (Their time will come later.)
Reduced the Lvalue constructors to a kernel of three constructors.
Updated all call sites that used the other contructors to uniformly
call `Lvalue::new_with_hint`, passing along the appropriate kind
of hint for each context.
Add dropflag hints (stack-local booleans) for unfragmented paths in trans.
Added code to maintain these hints at runtime, and to conditionalize
drop-filling and calls to destructors.
In this early stage, we are using hints, so we are always free to
leave out a flag for a path -- then we just pass `None` as the
dropflag hint in the corresponding schedule cleanup call. But, once a
path has a hint, we must at least maintain it: i.e. if the hint
exists, we must ensure it is never set to "moved" if the data in
question might actually have been initialized. It remains sound to
conservatively set the hint to "initialized" as long as the true
drop-flag embedded in the value itself is up-to-date.
----
Here are some high-level details I want to point out:
* We maintain the hint in Lvalue::post_store, marking the lvalue as
moved. (But also continue drop-filling if necessary.)
* We update the hint on ExprAssign.
* We pass along the hint in once closures that capture-by-move.
* You only call `drop_ty` for state that does not have an associated hint.
If you have a hint, you must call `drop_ty_core` instead.
(Originally I passed the hint into `drop_ty` as well, to make the
connection to a hint more apparent, but the vast majority of
current calls to `drop_ty` are in contexts where no hint is
available, so it just seemed like noise in the resulting diff.)
Extend `trans::datum::Lvalue` so that it carrys an optional dropflag hint.
Instrumented calls sites that construct Lvalues to ease tracking down
cases that we might need to change whether or not they carry a hint.
Note that this commit does not do anything to actually *construct*
the `lldropflag_hints` map, nor does it change anything about codegen
itself. Those parts are in follow-on commits.
projects / rust.git / log