bors [Sun, 25 May 2014 01:56:19 +0000 (18:56 -0700)]
auto merge of #14402 : huonw/rust/arc-field-rename, r=alexcrichton
Paper over privacy issues with Deref by changing field names.
Types that implement Deref can cause weird error messages due to their
private fields conflicting with a field of the type they deref to, e.g.,
previously
struct Foo { x: int }
let a: Arc<Foo> = ...;
println!("{}", a.x);
would complain the the `x` field of `Arc` was private (since Arc has a
private field called `x`) rather than just ignoring it.
This patch doesn't fix that issue, but does mean one would have to write
`a._ptr` to hit the same error message, which seems far less
common. (This patch `_`-prefixes all private fields of
`Deref`-implementing types.)
Huon Wilson [Sat, 24 May 2014 11:35:53 +0000 (21:35 +1000)]
Paper over privacy issues with Deref by changing field names.
Types that implement Deref can cause weird error messages due to their
private fields conflicting with a field of the type they deref to, e.g.,
previously
struct Foo { x: int }
let a: Arc<Foo> = ...;
println!("{}", a.x);
would complain the the `x` field of `Arc` was private (since Arc has a
private field called `x`) rather than just ignoring it.
This patch doesn't fix that issue, but does mean one would have to write
`a._ptr` to hit the same error message, which seems far less
common. (This patch `_`-prefixes all private fields of
`Deref`-implementing types.)
bors [Sun, 25 May 2014 00:21:20 +0000 (17:21 -0700)]
auto merge of #14373 : sfackler/rust/unused-attr, r=huonw
The compiler now tracks which attributes were actually looked at during the compilation process and warns for those that were unused.
Some things of note:
* The tracking is done via thread locals, as it made the implementation more straightforward. Note that this shouldn't hamper any future parallelization as each task can have its own thread local state which can be merged for the lint pass. If there are serious objections to this, I can restructure things to explicitly pass the state around.
* There are a number of attributes that have to be special-cased and globally whitelisted. This happens for four reasons:
* The `doc` and `automatically_derived` attributes are used by rustdoc, but not by the compiler.
* The crate-level attributes `license`, `desc` and `comment` aren't currently used by anything.
* Stability attributes as well as `must_use` are checked only when the tagged item is used, so we can't guarantee that the compiler's looked at them.
* 12 attributes are used only in trans, which happens after the lint pass.
#14300 is adding infrastructure to track lint state through trans, which this lint should also be able to use to handle the last case. For the other attributes, the right solution would probably involve a specific pass to mark uses that occur in the correct context. For example, a `doc` attribute attached to a match arm should generate a warning, but will not currently.
Steven Fackler [Fri, 23 May 2014 05:29:13 +0000 (22:29 -0700)]
Get "make check" to work with unused-attribute
There's a fair number of attributes that have to be whitelisted since
they're either looked for by rustdoc, in trans, or as needed. These can
be cleaned up in the future.
bors [Sat, 24 May 2014 21:26:23 +0000 (14:26 -0700)]
auto merge of #14401 : aochagavia/rust/pr4, r=alexcrichton
Some functions implemented for the Ascii struct have the same functionality as other functions implemented for the normal chars. For consistency, I think they should have the same name, so I renamed the functions in Ascii to match the names in the Char trait.
* Renamed `to_lower` to `to_lowercase`
* Renamed `to_upper` to `to_uppercase`
* Renamed `is_alpha` to `is_alphabetic`
* Renamed `is_alnum` to `is_alphanumeric`
* Renamed `is_lower` to `is_lowercase`
* Renamed `is_upper` to `is_uppercase`
bors [Sat, 24 May 2014 11:56:25 +0000 (04:56 -0700)]
auto merge of #14396 : vhbit/rust/opaque-mutex, r=alexcrichton
On some systems (iOS for example) mutex is represented by opaque data structure which doesn't play well with simple data copy. Therefore mutex should be initialized from magic static value and filled by OS only when it landed RC.
Initially written for iOS but since landing iOS support might require quite a lot of time I think it is better to split parts which aren't directly related to iOS and merge them in
Adolfo Ochagavía [Sat, 24 May 2014 10:24:50 +0000 (12:24 +0200)]
Rename functions in Ascii
Some functions implemented for the Ascii struct have the same functionality as other functions implemented for the normal chars. For consistency, I think they should have the same name, so I renamed the functions in Ascii to match the names in the Char trait.
* Renamed `to_lower` to `to_lowercase`
* Renamed `to_upper` to `to_uppercase`
* Renamed `is_alpha` to `is_alphabetic`
* Renamed `is_alnum` to `is_alphanumeric`
* Renamed `is_lower` to `is_lowercase`
* Renamed `is_upper` to `is_uppercase`
bors [Sat, 24 May 2014 10:21:24 +0000 (03:21 -0700)]
auto merge of #14392 : alexcrichton/rust/mem-updates, r=sfackler
* All of the *_val functions have gone from #[unstable] to #[stable]
* The overwrite and zeroed functions have gone from #[unstable] to #[stable]
* The uninit function is now deprecated, replaced by its stable counterpart,
uninitialized
Valerii Hiora [Sat, 24 May 2014 05:01:23 +0000 (08:01 +0300)]
Fixes problems on systems with opaque mutex
On some systems (iOS for example) mutex is represented by
opaque data structure which doesn't play well with simple
data copy. Therefore mutex should be initialized from
magic static value and filled by OS only when it landed RC.
Alex Crichton [Sat, 24 May 2014 03:53:56 +0000 (20:53 -0700)]
core: Finish stabilizing the `mem` module.
* All of the *_val functions have gone from #[unstable] to #[stable]
* The overwrite and zeroed functions have gone from #[unstable] to #[stable]
* The uninit function is now deprecated, replaced by its stable counterpart,
uninitialized
bors [Sat, 24 May 2014 02:51:20 +0000 (19:51 -0700)]
auto merge of #14306 : luqmana/rust/up-llvm, r=alexcrichton
We can now mark arguments and returns as `nonnull` in LLVM. It's still somewhat limited by the fact that LLVM loses this information after inlining but it might help in certain cases.
Alex Crichton [Thu, 22 May 2014 17:49:26 +0000 (10:49 -0700)]
syntax: Clean out obsolete syntax parsing
All of these features have been obsolete since February 2014, where most have
been obsolete since 2013. There shouldn't be any more need to keep around the
parser hacks after this length of time.
bors [Fri, 23 May 2014 03:56:18 +0000 (20:56 -0700)]
auto merge of #14357 : huonw/rust/spelling, r=pnkfelix
The span on a inner doc-comment would point to the next token, e.g. the span for the `a` line points to the `b` line, and the span of `b` points to the `fn`.
bors [Fri, 23 May 2014 01:36:22 +0000 (18:36 -0700)]
auto merge of #14314 : alexcrichton/rust/deriving-hash, r=brson
One of the long-term goals of the libstd facade is to move the collections
library underneath the standard library. This would imply that libcollections
today would invert its dependency with libstd.
One of the primary blockers for doing this is the HashMap collection. Of its two
major dependencies, hashing and randomness, this commit is the first step in
dealing with hashing.
When moving the hash module beneath libstd, it must break its primary dependence
on the io::Writer trait (used as the hashing state). The proposed strategy for
breaking this dependence is taking a similar path as core::fmt, which is to have
the hash module define its own "writer trait". This trait would be similar to
std::io::Writer, except that it would not return errors and it would have fewer
convenience methods.
The Hash trait today has its type parameter behind a feature gate (default type
parameters), so this pending change will likely break no code which hasn't opted
in to the feature gate. The SipState struct will lose its implementation of
io::Writer, but it will regain similar methods for dealing with writing data.
This change specifically prepares for the hash migration by modifying
deriving(Hash) to use the std::hash::Writer bound instead of the std::io::Writer
bound. This bound is currently wired to std::io::Writer, but after a snapshot it
will have no need to be wired to the io writer trait.
bors [Thu, 22 May 2014 17:31:25 +0000 (10:31 -0700)]
auto merge of #14346 : alexcrichton/rust/rustdoc-external-crates, r=pcwalton
This commit alters rustdoc to crawl the metadata of upstream libraries in order
to fill in default methods for traits implemented in downstream crates. This,
for example, documents the `insert` function on hash maps.
This is a fairly lossy extraction from the metadata. Documentation and
attributes are lost, but they aren't used anyway. Unfortunately, argument names
are also lost because they are not present in the metadata. Source links are
also lost because the spans are not serialized.
While not perfect, it appears that presenting this documentation through rustdoc
is much better than nothing, so I wanted to land this to allow iteration on it
later on.
Alex Crichton [Sat, 3 May 2014 09:08:58 +0000 (02:08 -0700)]
rustdoc: Fill in external trait methods
This commit alters rustdoc to crawl the metadata of upstream libraries in order
to fill in default methods for traits implemented in downstream crates. This,
for example, documents the `insert` function on hash maps.
This is a fairly lossy extraction from the metadata. Documentation and
attributes are lost, but they aren't used anyway. Unfortunately, argument names
are also lost because they are not present in the metadata. Source links are
also lost because the spans are not serialized.
While not perfect, it appears that presenting this documentation through rustdoc
is much better than nothing, so I wanted to land this to allow iteration on it
later on.
bors [Thu, 22 May 2014 09:51:21 +0000 (02:51 -0700)]
auto merge of #14345 : alexcrichton/rust/rustdoc-many-impls, r=pcwalton
Right now, when you look in the "Implementors" section for traits, you only see
implementors within that crate. This commit modifies that section to include
implementors from neighboring crates as well.
For example, the Container trait currently says that it is only implemented by
strings and slices, but it is in fact implemented by nearly all containers.
Implementation-wise, this change generates an "implementors cache" similarly to
the search index where each crate will append implementors to the files. When
the page for a trait is loaded, it will load its specific cache file, rendering
links for all upstream types which implement the trait.
Alex Crichton [Wed, 21 May 2014 23:41:58 +0000 (16:41 -0700)]
rustdoc: Show types for traits across crates
Right now, when you look in the "Implementors" section for traits, you only see
implementors within that crate. This commit modifies that section to include
implementors from neighboring crates as well.
For example, the Container trait currently says that it is only implemented by
strings and slices, but it is in fact implemented by nearly all containers.
Implementation-wise, this change generates an "implementors cache" similarly to
the search index where each crate will append implementors to the files. When
the page for a trait is loaded, it will load its specific cache file, rendering
links for all upstream types which implement the trait.
Alex Crichton [Wed, 21 May 2014 03:06:33 +0000 (20:06 -0700)]
std: Change hash to reexport its own Writer
One of the long-term goals of the libstd facade is to move the collections
library underneath the standard library. This would imply that libcollections
today would invert its dependency with libstd.
One of the primary blockers for doing this is the HashMap collection. Of its two
major dependencies, hashing and randomness, this commit is the first step in
dealing with hashing.
When moving the hash module beneath libstd, it must break its primary dependence
on the io::Writer trait (used as the hashing state). The proposed strategy for
breaking this dependence is taking a similar path as core::fmt, which is to have
the hash module define its own "writer trait". This trait would be similar to
std::io::Writer, except that it would not return errors and it would have fewer
convenience methods.
The Hash trait today has its type parameter behind a feature gate (default type
parameters), so this pending change will likely break no code which hasn't opted
in to the feature gate. The SipState struct will lose its implementation of
io::Writer, but it will regain similar methods for dealing with writing data.
This change specifically prepares for the hash migration by modifying
deriving(Hash) to use the std::hash::Writer bound instead of the std::io::Writer
bound. This bound is currently wired to std::io::Writer, but after a snapshot it
will have no need to be wired to the io writer trait.
bors [Wed, 21 May 2014 15:06:27 +0000 (08:06 -0700)]
auto merge of #14326 : huonw/rust/tiny-fixes, r=pnkfelix
The changes to flowgraph make invalid invocations slightly more forgiving by (trying to) provide slightly more information and by avoiding the ICE message.
Huon Wilson [Wed, 21 May 2014 12:21:11 +0000 (22:21 +1000)]
rustc: improve error messages from wrong --pretty flowgraph use.
This defers to .fatal and .span_fatal for errors (rather than `fail!`
which prints the ICE message). It also adds the span lookup when an id
doesn't correspond to a block, to show what it is pointing at.
It also makes the argument parser slightly looser, so that passing
`--pretty flowgraph` recognises the `flowgraph` part and suggests to use
an integer.
projects / rust.git / log