Rollup merge of #24216 - alexcrichton:stabilize-from-raw-os-error, r=aturon
This commit stabilizes the old `io::Error::from_os_error` after being renamed to
use the `raw_os_error` terminology instead. This function is often useful when
writing bindings to OS functions but only actually converting to an I/O error at
a later point.
Rollup merge of #24215 - alexcrichton:stabilize-clone-from, r=aturon
This method hasn't really changed since is inception, and it can often be a
nice performance win for some situations. This method also imposes no burden on
implementors or users of `Clone` as it's just a default method on the side.
Rollup merge of #24212 - alexcrichton:destabilize-begin-unwind, r=huonw
Now that we have a `#[allow_internal_unstable]` attribute for macros there's no
need for these two `begin_unwind` functions to be stable. Right now the `panic!`
interface is the only one we wish to stabilize, so remove the stability markers
from these functions.
While this is a breaking change, it is highly unlikely to break any actual code.
It is recommended to use the `panic!` macro instead if it breaks explicit calls
into `std::rt`.
Rollup merge of #24207 - kmcallister:llvm-plugin, r=brson
r? @brson
I'm using this to integrate rustc with [american-fuzzy-lop](http://lcamtuf.coredump.cx/afl/). Building with afl instrumentation is no different from loading any other plugin library.
I'd like this PR to include a `run-make` test with a custom LLVM pass; however I'm not sure it's worth the trouble of building C++ code and linking LLVM from the test suite (are there existing tests that do this?)
Rollup merge of #24205 - brson:debug, r=alexcrichton
This makes the default configuration fully optimized, with no debugging options, no llvm asserts, renames --enable-debug to --enable-debug-assertions, and adds --enable-debug as a blanket option that toggles various things, per #17665. It does not add a `--enable-release` flag since that would be a no-op.
Rollup merge of #24191 - nikomatsakis:issue-20791, r=pnkfelix
Modify the ExprUseVisitor to walk each part of an AutoRef, and in
particular to treat an AutoUnsize as as kind of \"instantaneous\" borrow
of the value being unsized. This prevents us from feeding uninitialized
data.
This caused a problem for the eager reborrow of comparison traits,
because that wound up introducing a \"double AutoRef\", which was not
being thoroughly checked before but turned out not to type check.
Fortunately, we can just remove that \"eager reborrow\" as it is no longer
needed now that `PartialEq` doesn't force both LHS and RHS to have the
same type (and even if we did have this problem, the better way would be
to lean on introducing a common supertype).
The idea here is if you don't want rust in /usr/local
you can put something like this is your .profile:
```
export RUSTUP_PREFIX=$HOME/.local/rust
export PATH=$PATH:${RUSTUP_PREFIX}/bin
export DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:${RUSTUP_PREFIX}/lib
```
Then when you run rustup, it will update the install
in ${RUSTUP_PREFIX} without having to remember to pass
an explicit --prefix argument every time.
Auto merge of #24168 - kballard:clone-for-extern-c-unsafe-fns, r=alexcrichton
We only implemented Clone on `extern "Rust" fn`s (for up to 8
parameters). This didn't cover `extern "C"` or `unsafe` (or
`unsafe extern "C"`) `fn`s, but there's no reason why they shouldn't be
cloneable as well.
The new impls are marked unstable because the existing impl for `extern
"Rust" fn`s is.
Alex Crichton [Wed, 8 Apr 2015 23:41:14 +0000 (16:41 -0700)]
std: Stabilize io::Error::from_raw_os_error
This commit stabilizes the old `io::Error::from_os_error` after being renamed to
use the `raw_os_error` terminology instead. This function is often useful when
writing bindings to OS functions but only actually converting to an I/O error at
a later point.
Alex Crichton [Wed, 8 Apr 2015 23:38:38 +0000 (16:38 -0700)]
std: Stabilize Clone::clone_from
This method hasn't really changed since is inception, and it can often be a
nice performance win for some situations. This method also imposes no burden on
implementors or users of `Clone` as it's just a default method on the side.
Alex Crichton [Wed, 8 Apr 2015 22:48:46 +0000 (15:48 -0700)]
std: Destabilize the internals of panic!
Now that we have a `#[allow_internal_unstable]` attribute for macros there's no
need for these two `begin_unwind` functions to be stable. Right now the `panic!`
interface is the only one we wish to stabilize, so remove the stability markers
from these functions.
While this is a breaking change, it is highly unlikely to break any actual code.
It is recommended to use the `panic!` macro instead if it breaks explicit calls
into `std::rt`.
Auto merge of #24029 - nagisa:print-locking, r=alexcrichton
write_fmt calls write for each formatted field. The default implementation of write_fmt is used,
which will call write on not-yet-locked stdout (and write locking after), therefore making print!
in multithreaded environment still interleave contents of two separate prints.
I’m not sure whether we want to do this change, though, because it has the same deadlock hazard which we tried to avoid by not locking inside write_fmt itself (see [this comment](https://github.com/rust-lang/rust/blob/80def6c2447d23a624e611417f24cf0ab2a5a676/src/libstd/io/stdio.rs#L267)).
Implement reentrant mutexes and make stdio use them
write_fmt calls write for each formatted field. The default implementation of write_fmt is used,
which will call write on not-yet-locked stdout (and write locking after), therefore making print!
in multithreaded environment still interleave contents of two separate prints.
This patch implements reentrant mutexes, changes stdio handles to use these mutexes and overrides
write_fmt to lock the stdio handle for the whole duration of the call.
Steve Klabnik [Wed, 8 Apr 2015 15:34:12 +0000 (11:34 -0400)]
Rollup merge of #24178 - steveklabnik:new_toc, r=nikomatsakis
Basically, the overall structure is this:
* Getting Started - getting an environment up and running
* Learn Rust - project-based learning the basics
* Effective Rust - higher level concepts that lead to writing good rust
* Syntax and Semantics - chunks of exactly what it sounds like
* Nightly Rust - unstable stuff, a staging area for documenting features
* Glossary - self-explanatory
There's a number of weaknesses with the current TOC, but I'll just focus on the strengths of the new one:
We start off with getting our environment set up. That's "getting started".
Then, we basically present you with two choices: do you want to start small, with bits of syntax? Or do you want to dive in with projects?
I'm guessing more people will choose the second, so that's the next part: "Learn Rust." I don't have any chapters here, but this would have an updated guessing game, a tutorial on building a little `wc` clone, and something else I haven't decided yet. Lots of options. But the idea is to just dive in and get your hands dirty. I'll heavily link to the 'syntax and semantics' sections that are relevant.
Then, a section I'm calling 'Effective Rust'. it feels greedy to steal that title, so I'm hoping to give it another name. These are higher-level things than syntax that Rust programmers should know: error handling is a great example. Most of these are sort of 'how do I use the standard library together' kinds of things. This also contains informations about systems programming that those new to it might not know: the stack vs the heap, for example.
Then, "Syntax and Semantics." This has one section for each bit of Rust. Small, focused, but explains _everything_. These are positioned to be almost entirely in-order, but heavily cross-link, so you can go out of order if you want to, but you can also use it as a reference.
Next, "Nightly Rust," where documenting unstable things goes. If we want to get good feedback on new features, they'll need to be documented, but we don't want to taint the main docs, so that's what this is for.
Finally, the glossary. Straightforward enough.
--------------------------------
This is going to be a terrible PR to review, so I just did the TOC re-organization, with basically no editing. So it'll be a bit jumbled at first. But next steps are to go through and edit / revise / tweak / add stuff to get it in tip-top shape for 1.0!
Steve Klabnik [Wed, 8 Apr 2015 15:34:12 +0000 (11:34 -0400)]
Rollup merge of #24167 - hauleth:remove-incorrect-example-from-mpsc, r=steveklabnik
As beta is now released and is "suggested" version of `rustc` then there should be no code (in documentation) that will not compile with it. This one does not.
So according to [this great talk](http://delete-your-code.herokuapp.com/), I am doing what should be done.
Steve Klabnik [Wed, 8 Apr 2015 15:34:12 +0000 (11:34 -0400)]
Rollup merge of #24149 - bombless:update-faq, r=steveklabnik
I think "let is used to introduce variables" is incorrent.
You can use
```rust
match (42, true) {
(x, y) => { /* ... */ }
}
```
to replace
```rust
let x = 42;
let y = true;
```
so it's nothing special for `let`.
Steve Klabnik [Wed, 8 Apr 2015 15:34:11 +0000 (11:34 -0400)]
Rollup merge of #24143 - michaelsproul:extended-errors, r=pnkfelix
I've taken another look at extended errors - fixing up the printing and adding a few more for match expressions.
With regards to printing, the previous behaviour was to just print the error message string directly, despite it containing indentation which caused it to overflow the standard terminal width of 80 columns (try `rustc --explain E0004`). The first approach I considered was to strip the leading whitespace from each line and lay out the text dynamically, inserting spaces in between. This approach became quite messy when taking multi-paragraph errors into account (and seemed overkill). The approach I settled on removes the indentation in the string itself and begins each message with a newline that is stripped before printing.
I feel like complete extended errors would be nice to have for 1.0.0 and I'm happy to spearhead an effort to get them written. Brian got me onto writing them at an SF meetup and I think it shouldn't be too hard to get the remaining 80 or so written with the help of people who don't really work on compiler innards.
Niko Matsakis [Wed, 8 Apr 2015 08:31:51 +0000 (04:31 -0400)]
Modify the ExprUseVisitor to walk each part of an AutoRef, and in
particular to treat an AutoUnsize as as kind of "instantaneous" borrow
of the value being unsized. This prevents us from feeding uninitialized
data.
This caused a problem for the eager reborrow of comparison traits,
because that wound up introducing a "double AutoRef", which was not
being thoroughly checked before but turned out not to type check.
Fortunately, we can just remove that "eager reborrow" as it is no longer
needed now that `PartialEq` doesn't force both LHS and RHS to have the
same type (and even if we did have this problem, the better way would be
to lean on introducing a common supertype).
Auto merge of #24021 - pnkfelix:fn-params-outlive-body, r=nikomatsakis
Encode more precise scoping rules for function params
Function params outlive everything in the body (incl temporaries). Thus if we assign them their own `CodeExtent`, the region inference can properly show that it is sound to have temporaries with destructors that reference the parameters (because such temporaries will be dropped before the parameters are dropped).
Auto merge of #24078 - whipsch:extra-token-msg, r=huonw
Addresses issue #22425. See `src/test/compile-fail/macro-incomplete-parse.rs` for a relevant test:
macro-incomplete-parse.rs:15:9: 15:10 error: macro expansion ignores token `,` and any following
macro-incomplete-parse.rs:15 , //~ ERROR macro expansion ignores token `,`
^
macro-incomplete-parse.rs:27:1: 27:17 note: caused by the macro expansion here; the usage of `ignored_item` is likely invalid in this context
macro-incomplete-parse.rs:27 ignored_item!();
^~~~~~~~~~~~~~~~
macro-incomplete-parse.rs:20:14: 20:15 error: macro expansion ignores token `,` and any following
macro-incomplete-parse.rs:20 () => ( 1, 2 ) //~ ERROR macro expansion ignores token `,`
^
macro-incomplete-parse.rs:30:5: 30:21 note: caused by the macro expansion here; the usage of `ignored_expr` is likely invalid in this context
macro-incomplete-parse.rs:30 ignored_expr!();
^~~~~~~~~~~~~~~~
macro-incomplete-parse.rs:24:14: 24:15 error: macro expansion ignores token `,` and any following
macro-incomplete-parse.rs:24 () => ( 1, 2 ) //~ ERROR macro expansion ignores token `,`
^
macro-incomplete-parse.rs:32:9: 32:23 note: caused by the macro expansion here; the usage of `ignored_pat` is likely invalid in this context
macro-incomplete-parse.rs:32 ignored_pat!() => (),
^~~~~~~~~~~~~~
This does not address the case of improper expansion inside of an impl { } as seen in issue #21607.
I'm not sure if the note text is ideal, but it can be refined if needed.
Rollup merge of #24132 - kwantam:master, r=alexcrichton
@mahkoh points out in #15628 that unicode.py does not use
normative data for Grapheme classes. This pr fixes that issue,
and does some minor cleanup of the unicode.py script.
In addition, GC_RegionalIndicator is renamed GC_Regional_Indicator
in order to stay in line with the Unicode class name definitions.
I have updated refs in u_str.rs, and verified that there are no
refs elsewhere in the codebase. However, in principle someone
using the unicode tables for their own purposes might see breakage
from this.
Kevin Ballard [Tue, 7 Apr 2015 19:36:39 +0000 (12:36 -0700)]
Add Clone impls for extern "C" and unsafe fns
We only implemented Clone on `extern "Rust" fn`s (for up to 8
parameters). This didn't cover `extern "C"` or `unsafe` (or `unsafe
extern "C"`) `fn`s, but there's no reason why they shouldn't be
cloneable as well.
The new impls are marked unstable because the existing impl for `extern
"Rust" fn`s is.
Rollup merge of #24113 - mbrubeck:doc-edit, r=steveklabnik
* Fix broken \"module-level documentation\" link on the [`trait Any` docs](http://doc.rust-lang.org/std/any/trait.Any.html) and related broken markup on the [`std::any` docs](http://doc.rust-lang.org/std/any/index.html).
* Remove an outdated or incorrect notice in the `BufRead::lines` docs. There is no such `read_string` function, and `lines` never returns an error.
Rollup merge of #24112 - joshtriplett:patch-1, r=steveklabnik
traits.md said:
If we add a `use` line right above `main` and make the right things public,
everything is fine:
However, the use line was actually placed at the top of the file instead. Move
the use line to right above main. That also makes the example more evocative
of cases where the module is defined in a separate file.
Auto merge of #24116 - zaeleus:rustdoc-codespan, r=alexcrichton
Because the current style for `code` in rustdoc is to prewrap whitespace, code spans that are hard wrapped in the source documentation are prematurely wrapped when rendered in HTML. [For example][2],
```
/// ...
/// type can be borrowed as multiple different types. In particular, `Vec<T>:
/// Borrow<Vec<T>>` and `Vec<T>: Borrow<[T]>`.
```
renders as
because "`Vec<T>: Borrow<Vec<T>>`" wraps to the next line in the source.
CommonMark 0.18 [[1]] specifies "interior spaces and line endings are collapsed into single spaces" for code spans, which would actually prevent this issue, but hoedown does not currently conform to the
CommonMark spec.
The added span-level callback attempts to adhere to how whitespace is handled as described by CommonMark, fixing the issue of early, unintentional wrapping of code spans in rendered HTML.
Auto merge of #24101 - remram44:fix-rustdoc-passes-help, r=nikomatsakis
The current help string ("space separated list") suggests that `--passes "pass1 pass2"` is expected; the orrect usage is `--passes pass1 --passes pass2`.
Auto merge of #23952 - Kimundi:more_string_pattern, r=alexcrichton
This adds the missing methods and turns `str::pattern` in a user facing module, as per RFC.
This also contains some big internal refactorings:
- string iterator pairs are implemented with a central macro to reduce redundancy
- Moved all tests from `coretest::str` into `collectionstest::str` and left a note to prevent the two sets of tests drifting apart further.
See https://github.com/rust-lang/rust/issues/22477
@mahkoh points out in #15628 that unicode.py does not use
normative data for Grapheme classes. This pr fixes that issue.
In addition, GC_RegionalIndicator is renamed GC_Regional_Indicator
in order to stay in line with the Unicode class name definitions.
I have updated refs in u_str.rs, and verified that there are no
refs elsewhere in the codebase. However, in principle someone
using the unicode tables for their own purposes might see breakage
from this.
Auto merge of #23857 - phildawes:libsyntax_nopanic, r=nikomatsakis
Hello!
I've been working towards a libsyntax without panics. See:
http://internals.rust-lang.org/t/changing-libsyntax-to-use-result-instead-of-panic/1670
This patch changes the internals of parser.rs to use Result<> rather than panicing. It keeps the following old-style panicing functions as a facade:
parse_expr, parse_item, parse_pat, parse_arm, parse_ty, parse_stmt
I left these functions because I wasn't sure what to do about the quote_* macros or how many syntax-extensions would break if these and quoting macros returned Result.
The gyst of the rest of the patch is:
- Functions in parse/parser.rs return PResult<> rather than panicing
- Other functions in libsyntax call panic! explicitly if they rely on panicing behaviour.
- I added a macro 'panictry!()' to act as scaffolding for callers while converting panicing functions. (This does the same as 'unwrap()' but is easier to grep for and turn into try!()).
Am I on the right track? I'd quite like to get something merged soon as keeping this rebased in the face of libsyntax changes is a lot of work. Please let me know what changes you'd like to see to make this happen.
projects / rust.git / log