Commit Graph

27976 Commits

Author SHA1 Message Date
Tobias Bucher
a5dcbc66db Remove RUST_LOG="::help" from the docs
This feature is no longer present in the current version, it was removed along
with the crate map.
2014-04-15 19:45:00 -07:00
bors
6fcf43e50e auto merge of #13511 : Meyermagic/rust/enum_typeid, r=alexcrichton
Fixes #13507.

I haven't familiarized myself with this part of the rust compiler, so hopefully there are no mistakes (despite the simplicity of the commit). It is also 5am.
2014-04-15 17:31:54 -07:00
bors
10f94e3fe5 auto merge of #13164 : ktt3ja/rust/lifetime-suggestion-method, r=nmatsakis
This includes a change to the way lifetime names are generated. Say we
figure that `[#0, 'a, 'b]` have to be the same lifetimes, then instead
of just generating a new lifetime `'c` like before to replace them, we
would reuse `'a`. This is done so that when the lifetime name comes
from an impl, we don't give something that's completely off, and we
don't have to do much work to figure out where the name came from. For
example, for the following code snippet:

```rust
struct Baz<'x> {
    bar: &'x int
}

impl<'x> Baz<'x> {
    fn baz1(&self) -> &int {
        self.bar
    }
}
```

`[#1, 'x]` (where `#1` is BrAnon(1) and refers to lifetime of `&int`)
have to be marked the same lifetime. With the old method, we would
generate a new lifetime `'a` and suggest `fn baz1(&self) -> &'a int`
or `fn baz1<'a>(&self) -> &'a int`, both of which are wrong.
2014-04-15 14:16:54 -07:00
Kiet Tran
79d1e5df21 Support lifetime suggestion for method
This includes a change to the way lifetime names are generated. Say we
figure that `[#0, 'a, 'b]` have to be the same lifetimes, then instead
of just generating a new lifetime `'c` like before to replace them, we
would reuse `'a`. This is done so that when the lifetime name comes
from an impl, we don't give something that's completely off, and we
don't have to do much work to figure out where the name came from. For
example, for the following code snippet:

```rust
struct Baz<'x> {
    bar: &'x int
}

impl<'x> Baz<'x> {
    fn baz1(&self) -> &int {
        self.bar
    }
}
```

`[#1, 'x]` (where `#1` is BrAnon(1) and refers to lifetime of `&int`)
have to be marked the same lifetime. With the old method, we would
generate a new lifetime `'a` and suggest `fn baz1(&self) -> &'a int`
or `fn baz1<'a>(&self) -> &'a int`, both of which are wrong.
2014-04-15 15:47:47 -04:00
bors
189584e792 auto merge of #13489 : JustAPerson/rust/crate-file-name, r=alexcrichton
Before, the `--crate-file-name` flag only checked crate attributes for
possible crate types. Now, if any type is specified by one or more
`--crate-type` flags, only the filenames for those types will be
emitted, and any types specified by crate attributes will be ignored.
2014-04-15 11:02:03 -07:00
bors
8a4ffbf625 auto merge of #13416 : brson/rust/30min, r=alexcrichton
This is intended to be the first thing somebody new to the language reads about Rust. It is supposed to be simple and intriguing, to give the user an idea of whether Rust is appropriate for them, and to hint that there's a lot of cool stuff to learn if they just keep diving deeper.

I'm particularly happy with the sequence of concurrency examples.
2014-04-15 06:02:06 -07:00
Brian Anderson
d1eb0e393f doc: Address feedback about intro 2014-04-14 20:49:29 -07:00
Meyer S. Jacobs
b9f7ac591c Fixes #13507
Fixes hashing of DefId for ty_enum.

Adds tests for cross-crate TypeId equivalence for various types.
2014-04-14 17:39:52 -07:00
JustAPerson
0162f8e6e1 Only check --crate-type flags if present.
Before, normal compilation and the --crate-file-name flag would
generate output based on both #![crate_type] attributes and
--crate-type flags. Now, if one or more flag is specified by command
line, only those will be used.

Closes #11573.
2014-04-14 16:53:06 -05:00
bors
168b2d1a3f auto merge of #13496 : alexcrichton/rust/issue-13495, r=sfackler
This bug was introduced in #13384 by accident, and this commit continues the
work of #13384 by finishing support for loading a syntax extension crate without
registering it with the local cstore.

Closes #13495
2014-04-14 14:36:54 -07:00
bors
246ebd2d5a auto merge of #13493 : Manishearth/rust/newattr-everywhere, r=alexcrichton
See #13478
2014-04-14 12:21:52 -07:00
bors
347e9e4ffe auto merge of #13480 : edwardw/rust/vtable-ice, r=alexcrichton
A mismatched type with more type parameters than the expected one causes
`typeck` looking up out of the bound of type parameter vector, which
leads to ICE.

Closes #13466
2014-04-14 11:00:20 -07:00
bors
2f41a85d8e auto merge of #13431 : lifthrasiir/rust/rustdoc-smaller-index, r=alexcrichton
This is a series of inter-related commits which depend on #13402 (Prune the paths that do not appear in the index). Please consider this as an early review request; I'll rebase this when the parent PR get merged and rebase is required.

----

This PR aims at reducing the search index without removing the actual information. In my measurement with both library and compiler docs, the search index is 52% smaller before gzipped, and 16% smaller after gzipped:

```
 1719473 search-index-old.js
 1503299 search-index.js (after #13402, 13% gain)
  724955 search-index-new.js (after this PR, 52% gain w.r.t. #13402)

  262711 search-index-old.js.gz
  214205 search-index.js.gz (after #13402, 18.5% gain)
  179396 search-index-new.js.gz (after this PR, 16% gain w.r.t. #13402)
```

Both the uncompressed and compressed size of the search index have been accounted. While the former would be less relevant when #12597 (Web site should be transferring data compressed) is resolved, the uncompressed index will be around for a while anyway and directly affects the UX of docs. Moreover, LZ77 (and gzip) can only remove *some* repeated strings (since its search window is limited in size), so optimizing for the uncompressed size often has a positive effect on the compressed size as well.

Each commit represents the following incremental improvements, in the order:

1. Parent paths were referred by its AST `NodeId`, which tends to be large. We don't need the actual node ID, so we remap them to the smaller sequential numbers. This also means that the list of paths can be a flat array instead of an object.
2. We remap each item type to small predefined numbers. This is strictly intended to reduce the uncompressed size of the search index.
3. We use arrays instead of objects and reconstruct the original objects in the JavaScript code. Since this removes a lot of boilerplates, this affects both the uncompressed and compressed size.
4. (I've found that a centralized `searchIndex` is easier to handle in JS, so I shot one global variable down.)
5. Finally, the repeated paths in the consecutive items are omitted (replaced by an empty string). This also greatly affects both the uncompressed and compressed size.

There had been several unsuccessful attempts to reduce the search index. Especially, I explicitly avoided complex optimizations like encoding paths in a compressed form, and only applied the optimizations when it had a substantial gain compared to the changes. Also, while I've tried to be careful, the lack of proper (non-smoke) tests makes me a bit worry; any advice on testing the search indices would be appreciated.
2014-04-14 08:36:56 -07:00
Manish Goregaokar
713e87526e Use new attribute syntax in python files in src/etc too (#13478) 2014-04-14 21:00:31 +05:30
bors
e2e754810c auto merge of #13477 : Manishearth/rust/newattr, r=brson
See #13476
2014-04-14 07:11:53 -07:00
bors
5dd94d86c6 auto merge of #13481 : huonw/rust/devec-path, r=alexcrichton
Remove the use of ~[] from Path's internals.
2014-04-14 01:41:48 -07:00
bors
40a9797751 auto merge of #13479 : sfackler/rust/result-unwrap, r=cmr
`foo.ok().unwrap()` and `foo.err().unwrap()` are the fallbacks for types
that aren't `Show`.

Closes #13379
2014-04-14 00:16:49 -07:00
Steven Fackler
eb0473df93 Make Result::{unwrap, unwrap_err} require Show
`foo.ok().unwrap()` and `foo.err().unwrap()` are the fallbacks for types
that aren't `Show`.

Closes #13379
2014-04-13 23:47:53 -07:00
bors
bb9b2e0ebe auto merge of #13475 : Ryman/rust/result_unwrap_or_else, r=brson
It might make more sense to mirror `Option`'s `unwrap_or_else` but I've left it as `handle` as it feels more explicit about the signature difference.
2014-04-13 19:36:50 -07:00
Kang Seonghoon
8f5d71cf71 rustdoc: Omit repeated paths in the search index.
Since the items roughly follow the lexical order, there are
many consecutive items with the same path value which can be
easily compressed.

For the library and compiler docs, this commit decreases
the index size by 26% and 6% before and after gzip, respectively.
2014-04-14 10:00:50 +09:00
Kang Seonghoon
9eb336a020 rustdoc: Get rid of allPaths global variable by merging it into searchIndex. 2014-04-14 10:00:49 +09:00
Kang Seonghoon
f6854ab46c rustdoc: Use an array instead of an object for the search index.
`buildIndex` JS function recovers them into the original object form.
This greatly reduces the size of the uncompressed search index (27%),
while this effect is less visible after gzipped (~5%).
2014-04-14 10:00:49 +09:00
Kang Seonghoon
f1de04c760 rustdoc: Represent item types as a small number in the search index.
Has negligible improvements with gzip, but saves about 7% without it.
This also has an effect of changing the tie-breaking order of item types.
2014-04-14 10:00:48 +09:00
Kang Seonghoon
ab6915d7b5 rustdoc: Use smaller sequential numbers instead of NodeIds for parents.
`allPaths` is now a flat array in effect. This decreases the size of
the search index by about 4--5% (gzipped or not).
2014-04-14 09:59:17 +09:00
bors
5d284a0daa auto merge of #13464 : alexcrichton/rust/fix-rustdoc-rendering, r=brson
Closures did not have their bounds printed at all, nor their lifetimes. Trait
bounds were also printed in angle brackets rather than after a colon with a '+'
inbetween them.

Note that on the current task::spawn [1] documentation page, there is no mention
of a `Send` bound even though it is crucially important!

[1] - http://static.rust-lang.org/doc/master/std/task/fn.task.html
2014-04-13 15:51:46 -07:00
bors
296e60be6b auto merge of #13470 : Manishearth/rust/docnum, r=brson
See #7511
2014-04-13 13:36:48 -07:00
Alex Crichton
e163ab2151 rustc: Don't link in syntax extensions
This bug was introduced in #13384 by accident, and this commit continues the
work of #13384 by finishing support for loading a syntax extension crate without
registering it with the local cstore.

Closes #13495
2014-04-13 11:29:28 -07:00
Alex Crichton
44e34c24c4 rustdoc: Fix rendering closures and trait bounds
Closures did not have their bounds printed at all, nor their lifetimes. Trait
bounds were also printed in angle brackets rather than after a colon with a '+'
inbetween them.

Note that on the current task::spawn [1] documentation page, there is no mention
of a `Send` bound even though it is crucially important!

[1] - http://static.rust-lang.org/doc/master/std/task/fn.task.html
2014-04-13 10:56:05 -07:00
bors
465109df62 auto merge of #13452 : Ryman/rust/fix_uint_as_u, r=alexcrichton
Fixes #13359.
2014-04-13 10:36:47 -07:00
bors
7240fad25e auto merge of #13471 : Ryman/rust/feature_syntax_error, r=brson
The current error message is misleading, it asks users to add `#[feature(..)]` which ends up being treated as an outer attribute, which then has no error unless `attribute_usage` lint is enforced. The code will still fail and the user might not understand why.
2014-04-13 08:51:49 -07:00
bors
4c62ab109b auto merge of #13469 : kmcallister/rust/utf16, r=huonw
This fixes two separate issues related to character encoding.

* Add `encode_utf16` to the `Char` trait, analogous to `encode_utf8`.  `&str` already supports UTF-16 encoding but only with a heap allocation.  Also fix `encode_utf8` docs and add tests.

* Correctly decode non-BMP hex escapes in JSON (#13064).
2014-04-13 05:51:52 -07:00
bors
770b2fea06 auto merge of #13468 : alexcrichton/rust/issue-13467, r=thestinger
Previously, all slices derived from a vector whose values were of size 0 had a
null pointer as the 'data' pointer on the slice. This caused first pointer to be
yielded during iteration to always be the null pointer. Due to the null pointer
optimization, this meant that the first return value was None, instead of
Some(&T).

This commit changes slice construction from a Vec instance to use a base pointer
of 1 if the values have zero size. This means that the iterator will never
return null, and the iteration will proceed appropriately.

Closes #13467
2014-04-13 04:06:53 -07:00
bors
2f79054650 auto merge of #13463 : alexcrichton/rust/c-linkage-oh-my, r=brson
Previously, upstream C libraries were linked in a nondeterministic fashion
because they were collected through iter_crate_data() which is a nodeterministic
traversal of a hash map. When upstream rlibs had interdependencies among their
native libraries (such as libfoo depending on libc), then the ordering would
occasionally be wrong, causing linkage to fail.

This uses the topologically sorted list of libraries to collect native
libraries, so if a native library depends on libc it just needs to make sure
that the rust crate depends on liblibc.
2014-04-13 02:16:54 -07:00
bors
745a3ce458 auto merge of #13462 : alexcrichton/rust/fix-cross-rpath, r=brson
After removing absolute rpaths, cross compile builds (notably the nightly
builders) broke. This is because the RPATH was pointing at an empty directory
because only the rustc binary is copied over, not all of the target libraries.
This modifies the cross compile logic to fixup the rpath of the stage0
cross-compiled rustc to point to where it came from.
2014-04-13 00:51:54 -07:00
bors
96aeb7e3c3 auto merge of #13461 : eddyb/rust/cleanup-at-fn, r=luqmana 2014-04-12 22:21:56 -07:00
bors
e4178db07c auto merge of #13460 : SimonSapin/rust/patch-9, r=alexcrichton 2014-04-12 20:36:58 -07:00
bors
9d75f2387f auto merge of #13455 : alexcrichton/rust/jettison-timerfd, r=brson
Rust advertises itself as being compatible with linux 2.6.18, but the timerfd
set of syscalls weren't added until linux 2.6.25. There is no real need for a
specialized timer implementation beyond being a "little more accurate", but the
select() implementation will suffice for now.

If it is later deemed that an accurate timerfd implementation is needed, it can
be added then through some method which will allow the standard distribution to
continue to be compatible with 2.6.18

Closes #13447
2014-04-12 18:41:58 -07:00
Kevin Butler
888517df4d libsyntax: update helper to stringify TyU* and TyI* to take into account having a value.
Fixes #13359.
2014-04-13 02:39:19 +01:00
bors
82cd9ac884 auto merge of #13459 : alexcrichton/rust/stop-ignoring-ffi, r=sfackler
Using some strategically-placed `#` markers most of the examples are testable
(and their contents are nontrivial).

Closes #13445
2014-04-12 14:46:59 -07:00
Alex Crichton
28ba3a7bc3 native: Remove timerfd implementation on linux
Rust advertises itself as being compatible with linux 2.6.18, but the timerfd
set of syscalls weren't added until linux 2.6.25. There is no real need for a
specialized timer implementation beyond being a "little more accurate", but the
select() implementation will suffice for now.

If it is later deemed that an accurate timerfd implementation is needed, it can
be added then through some method which will allow the standard distribution to
continue to be compatible with 2.6.18

Closes #13447
2014-04-12 13:42:07 -07:00
bors
ab0d847277 auto merge of #13448 : alexcrichton/rust/rework-chan-return-values, r=brson
There are currently a number of return values from the std::comm methods, not
all of which are necessarily completely expressive:

 * `Sender::try_send(t: T) -> bool`
    This method currently doesn't transmit back the data `t` if the send fails
    due to the other end having disconnected. Additionally, this shares the name
    of the synchronous try_send method, but it differs in semantics in that it
    only has one failure case, not two (the buffer can never be full).

 * `SyncSender::try_send(t: T) -> TrySendResult<T>`
    This method accurately conveys all possible information, but it uses a
    custom type to the std::comm module with no convenience methods on it.
    Additionally, if you want to inspect the result you're forced to import
    something from `std::comm`.

 * `SyncSender::send_opt(t: T) -> Option<T>`
    This method uses Some(T) as an "error value" and None as a "success value",
    but almost all other uses of Option<T> have Some/None the other way

 * `Receiver::try_recv(t: T) -> TryRecvResult<T>`
    Similarly to the synchronous try_send, this custom return type is lacking in
    terms of usability (no convenience methods).

With this number of drawbacks in mind, I believed it was time to re-work the
return types of these methods. The new API for the comm module is:

    Sender::send(t: T) -> ()
    Sender::send_opt(t: T) -> Result<(), T>
    SyncSender::send(t: T) -> ()
    SyncSender::send_opt(t: T) -> Result<(), T>
    SyncSender::try_send(t: T) -> Result<(), TrySendError<T>>
    Receiver::recv() -> T
    Receiver::recv_opt() -> Result<T, ()>
    Receiver::try_recv() -> Result<T, TryRecvError>

The notable changes made are:

* Sender::try_send => Sender::send_opt. This renaming brings the semantics in
  line with the SyncSender::send_opt method. An asychronous send only has one
  failure case, unlike the synchronous try_send method which has two failure
  cases (full/disconnected).

* Sender::send_opt returns the data back to the caller if the send is guaranteed
  to fail. This method previously returned `bool`, but then it was unable to
  retrieve the data if the data was guaranteed to fail to send. There is still a
  race such that when `Ok(())` is returned the data could still fail to be
  received, but that's inherent to an asynchronous channel.

* Result is now the basis of all return values. This not only adds lots of
  convenience methods to all return values for free, but it also means that you
  can inspect the return values with no extra imports (Ok/Err are in the
  prelude). Additionally, it's now self documenting when something failed or not
  because the return value has "Err" in the name.

Things I'm a little uneasy about:

* The methods send_opt and recv_opt are not returning options, but rather
  results. I felt more strongly that Option was the wrong return type than the
  _opt prefix was wrong, and I coudn't think of a much better name for these
  methods. One possible way to think about them is to read the _opt suffix as
  "optionally".

* Result<T, ()> is often better expressed as Option<T>. This is only applicable
  to the recv_opt() method, but I thought it would be more consistent for
  everything to return Result rather than one method returning an Option.

Despite my two reasons to feel uneasy, I feel much better about the consistency
in return values at this point, and I think the only real open question is if
there's a better suffix for {send,recv}_opt.

Closes #11527
2014-04-12 12:21:58 -07:00
Alex Crichton
f862e1256d doc: Un-ignore lots of guide-ffi tests
Using some strategically-placed `#` markers most of the examples are testable
(and their contents are nontrivial).

Closes #13445
2014-04-12 12:18:45 -07:00
Edward Wang
fc043c054f Check bounds when looking up type parameters
A mismatched type with more type parameters than the expected one causes
`typeck` looking up out of the bound of type parameter vector, which
leads to ICE.

Closes #13466
2014-04-12 21:14:24 +08:00
Huon Wilson
31074fdf2e std: update & de-~[] path's tests. 2014-04-12 22:51:18 +10:00
Huon Wilson
1283caa8cb std: migrate path::windows to using StrBuf internally.
Same representation change performed with path::unix.

This also implements BytesContainer for StrBuf & adds an (unsafe) method
for viewing & mutating the raw byte vector of a StrBuf.
2014-04-12 22:51:11 +10:00
Huon Wilson
28e3340a07 std: migrate path::unix to using Vec internally. 2014-04-12 22:50:56 +10:00
Manish Goregaokar
d0aed0995b Update tutorials to use new attribute syntax (#13476) 2014-04-12 09:03:39 +05:30
Kevin Butler
a16eae6ffd libstd: Add unwrap_or and unwrap_or_handle to Result 2014-04-12 03:23:16 +01:00
Kevin Butler
c48a3efb17 librustc: Improve error message for missing feature attributes. 2014-04-12 00:25:32 +01:00
Manish Goregaokar
01d5d51daf Document traits in std::num (#7511) 2014-04-12 04:37:45 +05:30