Commit Graph

40450 Commits

Author SHA1 Message Date
Alex Crichton
b97e1cc28e rollup merge of #23541: aturon/stab-error
This small commit stabilizes the `Error` trait as-is, except that `Send`
and `Debug` are added as constraints. The `Send` constraint is because
most uses of `Error` will be for trait objects, and by default we would
like these objects to be transferrable between threads. The `Debug`
constraint is to ensure that e.g. `Box<Error>` is `Debug`, and because
types that implement `Display` should certainly implement `Debug` in any case.

In the near future we expect to add `Any`-like downcasting features to
`Error`, but this is waiting on some additional
mechanisms (`Reflect`). It will be added before 1.0 via default methods.

[breaking-change]

r? @alexcrichton

Closes #21790
2015-03-23 15:09:08 -07:00
Alex Crichton
fd13400627 rollup merge of #23538: aturon/conversion
Conflicts:
	src/librustc_back/rpath.rs
2015-03-23 15:09:05 -07:00
Alex Crichton
c77af69a37 rollup merge of #23536: pnkfelix/arith-oflo-shifts
overflow-checking for rhs of shift operators

Subtask of #22020 ([RFC 560](https://github.com/rust-lang/rfcs/blob/master/text/0560-integer-overflow.md))
2015-03-23 15:08:17 -07:00
Alex Crichton
68cf9e09c2 rollup merge of #23517: vhbit/ext-socket-options
Continuation of #23380 - added corresponding constants for Windows, Linux, *BSDs

r? @alexcrichton

Alex, can you also cc to a person who can check correctness for Windows as I'm not that confident in header file I've downloaded.
2015-03-23 15:08:15 -07:00
Alex Crichton
0678f0b10c rollup merge of #23515: nikomatsakis/issue-14985-trait-subtyping
Remove incorrect subtyping for `&mut Trait` and introduce coercion for `&mut (Trait+'a)` to `&mut (Trait+'b)` if `'a:'b`.

Fixes #14985.

r? @nrc
2015-03-23 15:08:13 -07:00
Alex Crichton
4f7437647f rollup merge of #23466: woehr/master
This fixes a bug in LLVM IR generation for in-line assembly where Rust would always use the host clobbers instead of target clobbers.

I also took this opportunity to clean/simplify the ```trans_inline_asm``` function.

This is my first Rust pull request; please let me know if I'm missing anything.
2015-03-23 15:08:10 -07:00
Alex Crichton
d3fbc149b3 rollup merge of #23401: tshepang/crates-and-modules-doc-nits
Conflicts:
	src/doc/trpl/crates-and-modules.md
2015-03-23 15:08:01 -07:00
Alex Crichton
e98d4d9589 rollup merge of #23283: brson/rpathfix
Fix regression in -C rpath that causes failures with symlinks

The new `relative_from` method no longer supports the case on unix
where both paths are absolute, which `-C rpath` depended on. This
version fixes the problem by copying the old path_relative_from
function into the rpath module.

Fixes #23140

After experimenting with the new `relative_from` function on `Path` I'm not sure what it's use case is. It no longer even figures out that the relative path from `/foo/bar` to `/foo/baz/qux` is `../baz/qux`.
2015-03-23 15:07:33 -07:00
Alex Crichton
67e516c5c2 rollup merge of #23269: shepmaster/split-not-double-ended
Closes #23262
2015-03-23 15:07:23 -07:00
Alex Crichton
ec1a85a85c rollup merge of #23211: FlaPer87/oibit-send-and-friends
Fixes #23225

r? @nikomatsakis
2015-03-23 15:07:21 -07:00
Alex Crichton
ad41e7cd7a rollup merge of #23119: nikomatsakis/issue-23116-ref-mut
Don't allow upcasting to a supertype in the type of the match discriminant. Fixes #23116.

This is a [breaking-change] in that it closes a type hole that previously existed.

r? @pnkfelix
2015-03-23 15:07:19 -07:00
Alex Crichton
d6054e4771 rollup merge of #22954: ches/docs
Greetings Rustaceans!

I've just been getting acquainted with Rust through the guide. First let me say that it's already in great shape, chapters are kept a good length to be digestible and paced to move the reader along fluidly, so my compliments to contributors!

Along the way I noticed a few minor copy errors, and also a few areas that I thought more subjectively could stand to be improved. My commits here are divided so that minor edits unlikely to be very contentious could be cherry-picked, and then topically on parts that might generate more discussion.

I also have some comments and questions that aren't directly associated with any changes on this branch yet. I'm not sure how you like to triage this sort of thing but I'll present them below and if it's appropriate they could be moved to separate issues or I might be able to help work some of them out within the scope of this PR. Sorry that these are a lot to take in, pretty much everything below here can be digested independently of the current changes in this PR so you could read the rest later 😄

### Questions and Comments

I'll give stable links to doc revisions as of this writing.

1. The [example using `PartialEq` in the Traits chapter][1] is poor—we have no idea how `PartialEq` works at this point in the text (or at any point, AFAICT), so it isn't clear why it won't work as a trait bound in this situation and `Float` almost magically does, with the aid of existing tailor-made identity functions that seem unlikely to be so conveniently available when we encounter a scenario like this in our real-world code.

   This section just seems glossed over, or perhaps content has moved around over time or there's an assumption that implementing equality with `PartialEq` should be covered in the guide eventually so this example will be less foreign. As it stands the text is hard to follow and not very meaningful.
2. I found treatment of the relationship of trait objects to pointers in the *Static and Dynamic Dispatch* chapter unclear. [The "Why Pointers?" section][2] opens with this line:

   > The use of language like "fat pointer" implies that a trait object is always a pointer of some form, but why?

   But the phrase "fat pointer" hasn't been used anywhere before. This is some of the more complex material in the guide, but this section nevertheless feels displaced, not clearly connecting preceding subject matter. Earlier we've covered the internal representation of trait objects and significance of pointers they contain, but it hasn't been spelled out (other than what `&Foo` syntax suggests) that trait objects are references (and why). That's what the "Why Pointers?" section is aiming to do I gather, but it seems out of place, I think it'd make more sense to cover this before the gory details of their internals.
3. Suggestion: move the *Error Handling* chapter much earlier in the Intermediate section of the guide, or even into the Basics section. I know the Intermediate section isn't intended to be read in order per se, but plenty of people like me are just going to read it straight through anyway 😁 These are pretty fundamental concepts to understand and `Option`, `Result`, and idioms like `unwrap()` and `.ok().expect()` are referenced numerous times throughout the rest of the guide. They feature pretty prominently as early as *Standard Input* and *Guessing Game* chapters in Basics, in fact. I happen to have a good understanding of these already through encountering their analogs in typed functional languages, but if I didn't I believe I really would have appreciated reading *Error Handling* much earlier.
4. In the `rustdoc` chapter, a [comment at the beginning of the first source example][3] refers to a "link" crate attribute being needed. There seems to be no such attribute present in the source. I believe this refers to `crate_type` [according to the reference][4], but it'd be nice if this example were updated/clarified (I think `crate_id` is deprecated/obsolete too).

   This brings me to a related comment also: after encountering crate attributes in the reference and also docs on Cargo configuration like `crate-type = ["dylib"]`, I'm uncertain about the relationship/redundancy between these. I'm sure this is the kind of thing where docs are simply struggling to keep pace with rapid changes in Rust and Cargo, just wanted to flag that this distinction ought to be clearly covered in the docs for one or the other at some point, it's presently hard to track down.
5. Minor: link to sample editor configurations in [the introductory chapter][5] is broken, probably the generator automatically translates `.md` links to `.html`. Perhaps it shouldn't do that for absolute URLs.
6. Following from my changes to the enums coverage in [*Compound Data Types*][6] in this PR: sum types are an important topic and I tried to make some improvements, but I think the motivating example of `Character` with `Digit(i32)` and `Other` variants is a pretty weak one, and a better example could greatly improve cohesion with the `Ordering` coverage later in the section and how that ties into pattern matching in the subsequent chapter. I just haven't thought of a better example to suggest yet.

   In particular, the text states:

   > This may seem rather limiting, but it's a limitation which we can overcome.

   This is referring to `Character`, and actually to more than one limitation: the preceding admonition that its variants aren't comparable/don't have ordering, and don't support binary operators like `*` and `+`. Overcoming these limitations actually never gets explained—we next cover how `Ordering` works as an enum itself for plain `i32`s, but never get around to showing how this might be applied to our `Digit` variant type.

   Since the coverage of enums already segues into pattern matching and this could be even tighter with a stronger example, it might be nice if our example enum were somehow connected to the final example program for the Basics section too, where `Ordering` reappears. I don't see how it would fit with the current guessing game example, but food for thought.
7. `#[derive]` seems conspicuously missing from the guide. It would probably make sense to introduce after showing simple examples of implementing equality and/or ordering traits by hand, which have been mentioned as possibilities above. Perhaps it's too much to breach this as early as the Basic section though without traits being introduced. `#[derive]` itself and the derivable traits can certainly be saved for Intermediate and referenced as covered later, in any case.

r? @steveklabnik for docs.

[1]: 1576142495/src/doc/trpl/traits.md (our-inverse-example)
[2]: 1576142495/src/doc/trpl/static-and-dynamic-dispatch.md (why-pointers)
[3]: 1576142495/src/doc/trpl/documentation.md (creating-documentation)
[4]: http://doc.rust-lang.org/reference.html#linkage
[5]: 1576142495/src/doc/trpl/hello-world.md
[6]: 1576142495/src/doc/trpl/compound-data-types.md (enums)
2015-03-23 15:07:18 -07:00
Niko Matsakis
76ead08108 Remove auto-deref'ing Pattern impl because it conflicts with other
possible blanket impls and also triggers internal overflow. Add some
special cases for common uses (&&str, &String) for now; bounds-targeting
deref coercions are probably the right longer term answer.
2015-03-23 18:05:20 -04:00
Niko Matsakis
8bd8466e81 Refactor how we handle overflow so that it is a fatal error that aborts
compilation: this removes all the ungainly code that special cases
overflow so that we can ensure it propagates.
2015-03-23 18:05:20 -04:00
Alex Crichton
d97d53891d std: Stabilize the Hasher::finish method
This commit enables writing a stable implementation of the `Hasher` trait as
well as actually calculating the hash of a vlaue in a stable fashion. The
signature is stabilized as-is.
2015-03-23 15:03:07 -07:00
Aaron Turon
8389253df0 Add generic conversion traits
This commit:

* Introduces `std::convert`, providing an implementation of
RFC 529.

* Deprecates the `AsPath`, `AsOsStr`, and `IntoBytes` traits, all
in favor of the corresponding generic conversion traits.

  Consequently, various IO APIs now take `AsRef<Path>` rather than
`AsPath`, and so on. Since the types provided by `std` implement both
traits, this should cause relatively little breakage.

* Deprecates many `from_foo` constructors in favor of `from`.

* Changes `PathBuf::new` to take no argument (creating an empty buffer,
  as per convention). The previous behavior is now available as
  `PathBuf::from`.

* De-stabilizes `IntoCow`. It's not clear whether we need this separate trait.

Closes #22751
Closes #14433

[breaking-change]
2015-03-23 15:01:45 -07:00
Brian Anderson
8c93a79e38 rustdoc: Replace no-pretty-expanded with pretty-expanded
Now that features must be declared expanded source often does not compile.
This adds 'pretty-expanded' to a bunch of test cases that still work.
2015-03-23 14:40:26 -07:00
Brian Anderson
e9019101a8 Add #![feature] attributes to doctests 2015-03-23 14:40:26 -07:00
Brian Anderson
df290f127e Require feature attributes, and add them where necessary 2015-03-23 14:40:26 -07:00
Brian Anderson
7770ea706b rustdoc: Add #[doc(test(no_inject_crate))] attribute
So that collections doctests don't automatically fail themselves
by injecting `extern crate collections` when they are mostly
using the std facade.
2015-03-23 14:40:25 -07:00
Brian Anderson
3d365f6a01 rustdoc: interpret all leading feature attributes in examples as crate attributes
This makes it possible to write `#![feature(foo)]` in doc tests.
2015-03-23 14:40:25 -07:00
Brian Anderson
1aa75cea1d configure: Fix detection of 32-bit Linux userspace
The variable '$SHELL' is not actually defined by 'sh'.
2015-03-23 14:27:09 -07:00
Steve Klabnik
6a5b1e9f8e Rollup merge of #23641 - steveklabnik:gh23632, r=alexcrichton
Fixes #23632
2015-03-23 17:05:46 -04:00
Steve Klabnik
68af512123 Rollup merge of #23639 - steveklabnik:gh21305, r=alexcrichton
Fixes #21305

Not sure if we should include more than this here, but it should be good to have at least this.
2015-03-23 17:05:45 -04:00
Steve Klabnik
1c25aecf67 Rollup merge of #23622 - steveklabnik:gh23196, r=alexcrichton
Fixes #23196
2015-03-23 17:05:45 -04:00
Steve Klabnik
71b9ba1e5b Rollup merge of #23618 - steveklabnik:gh23571, r=alexcrichton
Fixes #23571
2015-03-23 17:05:45 -04:00
Steve Klabnik
8b6c0fd410 Rollup merge of #23608 - nagisa:refine-cursor-docstring, r=steveklabnik
r? @steveklabnik
2015-03-23 17:05:45 -04:00
Steve Klabnik
9299446030 Rollup merge of #23607 - mahkoh:cursor, r=alexcrichton
Closes #23599

r? @alexcrichton
2015-03-23 17:05:44 -04:00
Steve Klabnik
73b30db42d Rollup merge of #23590 - FuGangqiang:attr, r=alexcrichton 2015-03-23 17:05:44 -04:00
Steve Klabnik
61e690405a Rollup merge of #23561 - steveklabnik:gh23422, r=alexcrichton
Fixes #23422
2015-03-23 17:05:44 -04:00
Steve Klabnik
84f760b50a Rollup merge of #23509 - aturon:stab-entry, r=Gankro
This commit marks as `#[stable]` the `Entry` types for the maps provided
by `std`. The main reason these had been left unstable previously was
uncertainty about an eventual trait design, but several plausible
designs have been proposed that all work fine with the current type definitions.

r? @Gankro
2015-03-23 17:05:44 -04:00
Steve Klabnik
f788159797 Rollup merge of #23119 - nikomatsakis:issue-23116-ref-mut, r=pnkfelix
Don't allow upcasting to a supertype in the type of the match discriminant. Fixes #23116.

This is a [breaking-change] in that it closes a type hole that previously existed.

r? @pnkfelix
2015-03-23 17:05:43 -04:00
Steve Klabnik
4a81e66b44 Rollup merge of #22954 - ches:docs, r=steveklabnik
Greetings Rustaceans!

I've just been getting acquainted with Rust through the guide. First let me say that it's already in great shape, chapters are kept a good length to be digestible and paced to move the reader along fluidly, so my compliments to contributors!

Along the way I noticed a few minor copy errors, and also a few areas that I thought more subjectively could stand to be improved. My commits here are divided so that minor edits unlikely to be very contentious could be cherry-picked, and then topically on parts that might generate more discussion.

I also have some comments and questions that aren't directly associated with any changes on this branch yet. I'm not sure how you like to triage this sort of thing but I'll present them below and if it's appropriate they could be moved to separate issues or I might be able to help work some of them out within the scope of this PR. Sorry that these are a lot to take in, pretty much everything below here can be digested independently of the current changes in this PR so you could read the rest later 😄

### Questions and Comments

I'll give stable links to doc revisions as of this writing.

1. The [example using `PartialEq` in the Traits chapter][1] is poor—we have no idea how `PartialEq` works at this point in the text (or at any point, AFAICT), so it isn't clear why it won't work as a trait bound in this situation and `Float` almost magically does, with the aid of existing tailor-made identity functions that seem unlikely to be so conveniently available when we encounter a scenario like this in our real-world code.

   This section just seems glossed over, or perhaps content has moved around over time or there's an assumption that implementing equality with `PartialEq` should be covered in the guide eventually so this example will be less foreign. As it stands the text is hard to follow and not very meaningful.
2. I found treatment of the relationship of trait objects to pointers in the *Static and Dynamic Dispatch* chapter unclear. [The "Why Pointers?" section][2] opens with this line:

   > The use of language like "fat pointer" implies that a trait object is always a pointer of some form, but why?

   But the phrase "fat pointer" hasn't been used anywhere before. This is some of the more complex material in the guide, but this section nevertheless feels displaced, not clearly connecting preceding subject matter. Earlier we've covered the internal representation of trait objects and significance of pointers they contain, but it hasn't been spelled out (other than what `&Foo` syntax suggests) that trait objects are references (and why). That's what the "Why Pointers?" section is aiming to do I gather, but it seems out of place, I think it'd make more sense to cover this before the gory details of their internals.
3. Suggestion: move the *Error Handling* chapter much earlier in the Intermediate section of the guide, or even into the Basics section. I know the Intermediate section isn't intended to be read in order per se, but plenty of people like me are just going to read it straight through anyway 😁 These are pretty fundamental concepts to understand and `Option`, `Result`, and idioms like `unwrap()` and `.ok().expect()` are referenced numerous times throughout the rest of the guide. They feature pretty prominently as early as *Standard Input* and *Guessing Game* chapters in Basics, in fact. I happen to have a good understanding of these already through encountering their analogs in typed functional languages, but if I didn't I believe I really would have appreciated reading *Error Handling* much earlier.
4. In the `rustdoc` chapter, a [comment at the beginning of the first source example][3] refers to a "link" crate attribute being needed. There seems to be no such attribute present in the source. I believe this refers to `crate_type` [according to the reference][4], but it'd be nice if this example were updated/clarified (I think `crate_id` is deprecated/obsolete too).

   This brings me to a related comment also: after encountering crate attributes in the reference and also docs on Cargo configuration like `crate-type = ["dylib"]`, I'm uncertain about the relationship/redundancy between these. I'm sure this is the kind of thing where docs are simply struggling to keep pace with rapid changes in Rust and Cargo, just wanted to flag that this distinction ought to be clearly covered in the docs for one or the other at some point, it's presently hard to track down.
5. Minor: link to sample editor configurations in [the introductory chapter][5] is broken, probably the generator automatically translates `.md` links to `.html`. Perhaps it shouldn't do that for absolute URLs.
6. Following from my changes to the enums coverage in [*Compound Data Types*][6] in this PR: sum types are an important topic and I tried to make some improvements, but I think the motivating example of `Character` with `Digit(i32)` and `Other` variants is a pretty weak one, and a better example could greatly improve cohesion with the `Ordering` coverage later in the section and how that ties into pattern matching in the subsequent chapter. I just haven't thought of a better example to suggest yet.

   In particular, the text states:

   > This may seem rather limiting, but it's a limitation which we can overcome.

   This is referring to `Character`, and actually to more than one limitation: the preceding admonition that its variants aren't comparable/don't have ordering, and don't support binary operators like `*` and `+`. Overcoming these limitations actually never gets explained—we next cover how `Ordering` works as an enum itself for plain `i32`s, but never get around to showing how this might be applied to our `Digit` variant type.

   Since the coverage of enums already segues into pattern matching and this could be even tighter with a stronger example, it might be nice if our example enum were somehow connected to the final example program for the Basics section too, where `Ordering` reappears. I don't see how it would fit with the current guessing game example, but food for thought.
7. `#[derive]` seems conspicuously missing from the guide. It would probably make sense to introduce after showing simple examples of implementing equality and/or ordering traits by hand, which have been mentioned as possibilities above. Perhaps it's too much to breach this as early as the Basic section though without traits being introduced. `#[derive]` itself and the derivable traits can certainly be saved for Intermediate and referenced as covered later, in any case.

r? @steveklabnik for docs.

[1]: 1576142495/src/doc/trpl/traits.md (our-inverse-example)
[2]: 1576142495/src/doc/trpl/static-and-dynamic-dispatch.md (why-pointers)
[3]: 1576142495/src/doc/trpl/documentation.md (creating-documentation)
[4]: http://doc.rust-lang.org/reference.html#linkage
[5]: 1576142495/src/doc/trpl/hello-world.md
[6]: 1576142495/src/doc/trpl/compound-data-types.md (enums)
2015-03-23 17:05:43 -04:00
Tom Jakubowski
2df8830642 rustdoc: Support for "array" primitive
Impls on `clean::Type::FixedVector` are now collected in the array
primitive page instead of the slice primitive page.

Also add a primitive docs for arrays to `std`.
2015-03-23 14:02:34 -07:00
Niko Matsakis
57cf2decf7 Update borrowck tests to test that index is by-move now 2015-03-23 16:55:45 -04:00
Niko Matsakis
8e58af4004 Fallout in stdlib, rustdoc, rustc, etc. For most maps, converted uses of
`[]` on maps to `get` in rustc, since stage0 and stage1+ disagree about
how to use `[]`.
2015-03-23 16:55:45 -04:00
Niko Matsakis
b4d4daf007 Adjust Index/IndexMut impls. For generic collections, we take
references. For collections whose keys are integers, we take both
references and by-value.
2015-03-23 16:55:43 -04:00
Niko Matsakis
bc1dde468c Compiler and trait changes to make indexing by value. 2015-03-23 16:54:28 -04:00
Niko Matsakis
37601131a0 Make the Fn traits inherit from one another and remove the bridging
impls.

This requires:

1. modifying trait selection a bit so that when we synthesize impls for
   fn pointers and closures;
2. adding code to trans so that we can synthesize a `FnMut`/`FnOnce`
   impl for a `Fn` closure and so forth.
2015-03-23 16:46:02 -04:00
Steve Klabnik
1be8fcb4a9 Make note of str in 'more strings' chapter
Fixes #21035
2015-03-23 14:57:52 -04:00
Steve Klabnik
05c9728c69 Don't conflate regions and affine types
Fixes #23642
2015-03-23 14:47:14 -04:00
Aaron Turon
6bd3ab0d81 Implement RFC 909: move thread_local into thread
This commit implements [RFC
909](https://github.com/rust-lang/rfcs/pull/909):

The `std::thread_local` module is now deprecated, and its contents are
available directly in `std::thread` as `LocalKey`, `LocalKeyState`, and
`ScopedKey`.

The macros remain exactly as they were, which means little if any code
should break. Nevertheless, this is technically a:

[breaking-change]

Closes #23547
2015-03-23 11:28:54 -07:00
Aaron Turon
9231ceb6dd Stabilize the Error trait
This small commit stabilizes the `Error` trait as-is, except that `Send`
and `Debug` are added as constraints. The `Send` constraint is because
most uses of `Error` will be for trait objects, and by default we would
like these objects to be transferrable between threads. The `Debug`
constraint is to ensure that e.g. `Box<Error>` is `Debug`, and because
types that implement `Display` should certainly implement `Debug` in any case.

In the near future we expect to add `Any`-like downcasting features to
`Error`, but this is waiting on some additional
mechanisms (`Reflect`). It will be added before 1.0 via default methods.

[breaking-change]
2015-03-23 11:27:19 -07:00
Simonas Kazlauskas
d29d5545b6 prctl instead of pthread on linux for name setup
This is more portable as far as linux is concerned.
2015-03-23 20:08:12 +02:00
Steve Klabnik
d52c36246a Clarify that slices don't just point to arrays
Fixes #23632
2015-03-23 13:59:04 -04:00
Steve Klabnik
a5e1cbe191 Beef up BufRead::consume documentation.
Fixes #23196
2015-03-23 13:42:39 -04:00
Brian Anderson
9ec9bc68fb Clarify behavior of Path::relative_from 2015-03-23 10:22:17 -07:00
Brian Anderson
2625bf9ae4 Fix regression in -C rpath that causes failures with symlinks
The new `relative_from` method no longer supports the case on unix
where both paths are absolute, which `-C rpath` depended on. This
version fixes the problem by copying the old path_relative_from
function into the rpath module.

Fixes #23140
2015-03-23 10:21:54 -07:00
Julian Orth
d6fb7e9da8 derive missing trait implementations for cursor 2015-03-23 17:48:13 +01:00
Steve Klabnik
2750e3c83e Add note about pointer state after the call.
Fixes #23422
2015-03-23 12:21:53 -04:00