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.
bors [Wed, 21 May 2014 06:31:30 +0000 (23:31 -0700)]
auto merge of #14259 : alexcrichton/rust/core-mem, r=brson
Excluding the functions inherited from the cast module last week (with marked
stability levels), these functions received the following treatment.
* size_of - this method has become #[stable]
* nonzero_size_of/nonzero_size_of_val - these methods have been removed
* min_align_of - this method is now #[stable]
* pref_align_of - this method has been renamed without the
`pref_` prefix, and it is the "default alignment" now. This decision is in line
with what clang does (see url linked in comment on function). This function
is now #[stable].
* init - renamed to zeroed and marked #[stable]
* uninit - marked #[stable]
* move_val_init - renamed to overwrite and marked #[stable]
* {from,to}_{be,le}{16,32,64} - all functions marked #[stable]
* swap/replace/drop - marked #[stable]
* size_of_val/min_align_of_val/align_of_val - these functions are marked
#[unstable], but will continue to exist in some form. Concerns have been
raised about their `_val` prefix.
Alex Crichton [Sat, 17 May 2014 07:56:00 +0000 (00:56 -0700)]
core: Stabilize the mem module
Excluding the functions inherited from the cast module last week (with marked
stability levels), these functions received the following treatment.
* size_of - this method has become #[stable]
* nonzero_size_of/nonzero_size_of_val - these methods have been removed
* min_align_of - this method is now #[stable]
* pref_align_of - this method has been renamed without the
`pref_` prefix, and it is the "default alignment" now. This decision is in line
with what clang does (see url linked in comment on function). This function
is now #[stable].
* init - renamed to zeroed and marked #[stable]
* uninit - marked #[stable]
* move_val_init - renamed to overwrite and marked #[stable]
* {from,to}_{be,le}{16,32,64} - all functions marked #[stable]
* swap/replace/drop - marked #[stable]
* size_of_val/min_align_of_val/align_of_val - these functions are marked
#[unstable], but will continue to exist in some form. Concerns have been
raised about their `_val` prefix.
bors [Wed, 21 May 2014 04:36:25 +0000 (21:36 -0700)]
auto merge of #14293 : alexcrichton/rust/weak-lang-items, r=brson
This commit is part of the ongoing libstd facade efforts (cc #13851). The
compiler now recognizes some language items as "extern { fn foo(...); }" and
will automatically perform the following actions:
1. The foreign function has a pre-defined name.
2. The crate and downstream crates can only be built as rlibs until a crate
defines the lang item itself.
3. The actual lang item has a pre-defined name.
This is essentially nicer compiler support for the hokey
core-depends-on-std-failure scheme today, but it is implemented the same way.
The details are a little more hidden under the covers.
In addition to failure, this commit promotes the eh_personality and
rust_stack_exhausted functions to official lang items. The compiler can generate
calls to these functions, causing linkage errors if they are left undefined. The
checking for these items is not as precise as it could be. Crates compiling with
`-Z no-landing-pads` will not need the eh_personality lang item, and crates
compiling with no split stacks won't need the stack exhausted lang item. For
ease, however, these items are checked for presence in all final outputs of the
compiler.
It is quite easy to define dummy versions of the functions necessary:
Kevin Ballard [Wed, 21 May 2014 02:18:20 +0000 (19:18 -0700)]
Fix LLVM error with tuple struct match using (..)
Consider PatEnums constructed with A(..) to be candidates for tuple
struct patterns, not just ones constructed with A(a,b,c). If these
patterns shouldn't be valid tuple struct patterns (as they're equivalent
to _), this needs to be caught before we get to trans.
bors [Wed, 21 May 2014 02:16:15 +0000 (19:16 -0700)]
auto merge of #13823 : pnkfelix/rust/fsk-fix-13805, r=alexcrichton
Make configure script respect (and save) values for `CC`, `CXX`, `CFLAGS` etc.
I mostly tried to remain backwards compatible with old invocations of
the `configure` script; if you do not want to use `CC` et al., you
should not have to; you can keep using `--enable-clang` and/or
`--enable-ccache`.
The overall intention is to capture the following precedences for
guessing the C compiler:
1. Value of `CC` at `make` invocation time.
2. Value of `CC` at `configure` invocation time.
3. Compiler inferred at configure invocation time (`gcc` or `clang`).
The strategy is to check (at `configure` time) if each of the
environment variables is set, and if so, save its value in a
corresponding `CFG_` variable (e.g. `CFG_CC`).
The `configure` script also does not attempt to infer the compiler if
`CC` is set; but if `--enable-clang` was passed, then it *does* still
attempt to validate that the clang version is compatible.
Then, in the makefiles, if `CC` is not set but `CFG_CC` is, then we
use the `CFG_CC` setting as `CC`.
bors [Tue, 20 May 2014 22:41:20 +0000 (15:41 -0700)]
auto merge of #13975 : nikomatsakis/rust/issue-13794-fn-subtyping-and-static, r=pnkfelix
Tweak region inference to ignore constraints like `'a <= 'static`, since they
have no value. This also ensures that we can handle some obscure cases of fn
subtyping with bound regions that we didn't used to handle correctly.
Kevin Ballard [Tue, 20 May 2014 21:11:07 +0000 (14:11 -0700)]
vim: Handle box expressions specially
Attempt to highlight the placement expression in a `box (expr) foo`
expression. Also treat GC as a keyword within the placement expression.
This doesn't work correctly for arbitrary expressions. Notably, this
makes no attempt at balancing delimiters. I believe handling that will
require rewriting the syntax rules to add a region for every pair of
delimiters. That may be a desirable thing to do in the end, because we
can then rewrite our indent rules based on the syntax and get rid of
cindent(), but for the time being, we'll just live with the limitation.
projects / rust.git / log