auto merge of #15585 : bgamari/rust/subst-bug, r=pnkfelix
This branch has a fix for #15557 (a2bcef9) as well as a variety of patches I found useful while debugging this issue. These include adding `Show` impls to a variety of types, including the majority of `syntax::ast` and some of `middle::ty`.
Ben Gamari [Thu, 10 Jul 2014 18:05:28 +0000 (14:05 -0400)]
middle::kind: Don't crash when checking safety of Drop
To verify that a type can satisfy Send
`check_struct_safe_for_destructor` attempts to construct a new `ty::t`
an empty substitution list.
Previously the function would verify that the function has no type
parameters before attempting this. Unfortunately this check would not
catch functions with only regions parameters. In this case, the type
would eventually find its way to the substition engine which would
attempt to perform a substitution on the region parameters. As the
constructed substitution list is empty, this would fail, leading to a
compiler crash.
We fix this by verifying that types have both no type and region
parameters.
Ben Gamari [Tue, 8 Jul 2014 23:45:36 +0000 (19:45 -0400)]
typeck::check::_match: Better error handling
Previously this was an Option::unwrap() which failed for me.
Unfortunately I've since inadvertently worked around the bug and have
been unable to reproduce it. With this patch hopefully the next person
to encounter this will be in a slightly better position to debug it.
auto merge of #15619 : kwantam/rust/master, r=huonw
- `width()` computes the displayed width of a string, ignoring the width of control characters.
- arguably we might do *something* else for control characters, but the question is, what?
- users who want to do something else can iterate over chars()
- `graphemes()` returns a `Graphemes` struct, which implements an iterator over the grapheme clusters of a &str.
- fully compliant with [UAX#29](http://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries)
- passes all [Unicode-supplied tests](http://www.unicode.org/reports/tr41/tr41-15.html#Tests29)
- added code to generate additionial categories in `unicode.py`
- `Cn` aka `Not_Assigned`
- categories necessary for grapheme cluster breaking
- tidied up the exports from libunicode
- all exports are exposed through a module rather than directly at crate root.
- std::prelude imports UnicodeChar and UnicodeStrSlice from std::char and std::str rather than directly from libunicode
auto merge of #15426 : aochagavia/rust/str, r=alexcrichton
* Deprecated `str::from_utf8_owned` in favor of `String::from_utf8`
* Deprecated `str::from_utf8_lossy` in favor of `String::from_utf8_lossy`
* Deprecated `str::from_utf16` in favor of `String::from_utf16`
* Deprecated `str::from_utf16_lossy` in favor of `String::from_utf16_lossy`
* Deprecated `str::from_chars` in favor of `String::from_chars`
* Deprecated `str::from_char` in favor of `String::from_char` and `.to_string()`
* Deprecated `str::from_byte` in favor of `String::from_byte`
auto merge of #15371 : pnkfelix/rust/fsk-render-dataflow-on-dot, r=alexcrichton
Use one or more of the following `-Z` flag options to tell the
graphviz renderer to include the corresponding dataflow sets (after
the iterative constraint propagation reaches a fixed-point solution):
* `-Z flowgraph-print-loans` : loans computed via middle::borrowck
* `-Z flowgraph-print-moves` : moves computed via middle::borrowck::move_data
* `-Z flowgraph-print-assigns` : assignments, via middle::borrowck::move_data
* `-Z flowgraph-print-all` : all of the available sets are included.
Extend --pretty flowgraph=ID to include dataflow results in output.
Use one or more of the following `-Z` flag options to tell the
graphviz renderer to include the corresponding dataflow sets (after
the iterative constraint propagation reaches a fixed-point solution):
* `-Z flowgraph-print-loans` : loans computed via middle::borrowck
* `-Z flowgraph-print-moves` : moves computed via middle::borrowck::move_data
* `-Z flowgraph-print-assigns` : assignments, via middle::borrowck::move_data
* `-Z flowgraph-print-all` : all of the available sets are included.
Fix #15016.
----
This also adds a module, `syntax::ast_map::blocks`, that captures a
common abstraction shared amongst code blocks and procedure-like
things. As part of this, moved `ast_map.rs` to subdir
`ast_map/mod.rs`, to follow our directory layout conventions.
(incorporated review feedback from huon, acrichto.)
auto merge of #15511 : brson/rust/extract-rustc-back, r=alexcrichton
This was my weekend project, to start breaking up rustc. It first pulls out LLVM into `rustc_llvm`, then parts of `rustc::back` and `rustc::util` to `rustc_back`. The immediate intent is just to reduce the size of rustc, to reduce memory pressure when building rustc, but this is also a good starting point for further refactoring.
The `rustc_back` crate is definitely misnamed (`rustc::back` was never a very cohesive module anyway) - it's mostly just somewhere to stuff parts of rustc that don't have many deps. Right now it's main dep is `syntax`; it has no dep on `rustc_llvm`.
Some next steps might be to split `rustc_back` into `rustc_util` (with no `syntax` dep), and `rustc_syntax_util` (with a syntax dep); move the rest of `rustc::util` into `rustc_syntax_util`; move all of `rustc::front` to a new crate, `rustc_front`. At that point the refactoring necessary to keep extracting crates will get harder.
- Graphemes and GraphemeIndices structs implement iterators over
grapheme clusters analogous to the Chars and CharOffsets for chars in
a string. Iterator and DoubleEndedIterator are available for both.
- tidied up the exports for libunicode. crate root exports are now moved
into more appropriate module locations:
- UnicodeStrSlice, Words, Graphemes, GraphemeIndices are in str module
- UnicodeChar exported from char instead of crate root
- canonical_combining_class is exported from str rather than crate root
Since libunicode's exports have changed, programs that previously relied
on the old export locations will need to change their `use` statements
to reflect the new ones. See above for more information on where the new
exports live.
auto merge of #15227 : alexcrichton/rust/windows-unlink, r=brson
Currently when a read-only file has unlink() invoked on it on windows, the call
will fail. On unix, however, the call will succeed. In order to have a more
consistent behavior across platforms, this error is recognized on windows and
the file is changed to read-write before removal is attempted.
Alex Crichton [Fri, 27 Jun 2014 21:39:01 +0000 (14:39 -0700)]
std: Make unlink() more consistent
Currently when a read-only file has unlink() invoked on it on windows, the call
will fail. On unix, however, the call will succeed. In order to have a more
consistent behavior across platforms, this error is recognized on windows and
the file is changed to read-write before removal is attempted.
auto merge of #15655 : lightsofapollo/rust/glob-match-options-pub, r=alexcrichton
Not sure how to test this correctly I assume the current tests pass now because of the crate boundaries [and that this is fallout from private by default]?
auto merge of #15158 : alexcrichton/rust/windows-paths, r=brson
In order to have the spawning semantics be the same for unix/windows, the
child's PATH environment variable needs to be searched rather than the parent's
environment variable.
If the child is inheriting the parent's PATH, then no action need be taken as
windows will do the heavy lifting. If the child specifies its own PATH, then it
is searched beforehand for the target program and the result is favored if a hit
is found.
cc #15149, but does not close the issue because libgreen still needs to be
updated.
Alex Crichton [Tue, 24 Jun 2014 19:10:31 +0000 (12:10 -0700)]
native: Search the child's PATH on win32
In order to have the spawning semantics be the same for unix/windows, the
child's PATH environment variable needs to be searched rather than the parent's
environment variable.
If the child is inheriting the parent's PATH, then no action need be taken as
windows will do the heavy lifting. If the child specifies its own PATH, then it
is searched beforehand for the target program and the result is favored if a hit
is found.
cc #15149, but does not close the issue because libgreen still needs to be
updated.
auto merge of #15591 : aturon/rust/box-cell-stability, r=alexcrichton
This PR is the outcome of the library stabilization meeting for the
`liballoc::owned` and `libcore::cell` modules.
Aside from the stability attributes, there are a few breaking changes:
* The `owned` modules is now named `boxed`, to better represent its
contents. (`box` was unavailable, since it's a keyword.) This will
help avoid the misconception that `Box` plays a special role wrt
ownership.
* The `AnyOwnExt` extension trait is renamed to `BoxAny`, and its `move`
method is renamed to `downcast`, in both cases to improve clarity.
* The recently-added `AnySendOwnExt` extension trait is removed; it was
not being used and is unnecessary.
Stabilization for `owned` (now `boxed`) and `cell`
This PR is the outcome of the library stabilization meeting for the
`liballoc::owned` and `libcore::cell` modules.
Aside from the stability attributes, there are a few breaking changes:
* The `owned` modules is now named `boxed`, to better represent its
contents. (`box` was unavailable, since it's a keyword.) This will
help avoid the misconception that `Box` plays a special role wrt
ownership.
* The `AnyOwnExt` extension trait is renamed to `BoxAny`, and its `move`
method is renamed to `downcast`, in both cases to improve clarity.
* The recently-added `AnySendOwnExt` extension trait is removed; it was
not being used and is unnecessary.
auto merge of #15646 : jbclements/rust/method-macros, r=cmr
This patch adds support for macros in method position. It follows roughly the template for Item macros, where an outer `Method` wrapper contains a `Method_` enum which can either be a macro invocation or a standard macro definition.
One note; adding support for macros that expand into multiple methods is not included here, but should be a simple parser change, since this patch updates the type of fold_macro to return a smallvector of methods.
For reviewers, please pay special attention to the parser changes; these are the ones I'm most concerned about.
Because of the small change to the interface of fold_method, this is a ...
John Clements [Sat, 12 Jul 2014 04:22:11 +0000 (21:22 -0700)]
refactor Method definition to make space for macros
This change propagates to many locations, but because of the
Macro Exterminator (or, more properly, the invariant that it
protects), macro invocations can't occur downstream of expansion.
This means that in librustc and librustdoc, extracting the
desired field can simply assume that it can't be a macro
invocation. Functions in ast_util abstract over this check.
auto merge of #15507 : jakub-/rust/iterate, r=alexcrichton
The new iterator takes a function and produces an infinite stream
of results of repeated applications of the function, starting from
the provided seed value.
Jakub Wieczorek [Sun, 6 Jul 2014 22:50:53 +0000 (00:50 +0200)]
Add an iterate function to core::iter
Implementation by Kevin Ballard.
The function returns an Unfold iterator producing an infinite stream
of results of repeated applications of the function, starting from
the provided seed value.
auto merge of #15584 : alexcrichton/rust/warn-annoyances, r=cmr
* Don't warn about `#[crate_name]` if `--crate-name` is specified
* Don't warn about non camel case identifiers on `#[repr(C)]` structs
* Switch `mode` to `mode_t` in libc.
auto merge of #15621 : sfackler/rust/attr-span, r=cmr
They used to be one token too long, so you'd see things like
```
rust/rust/test.rs:1:1: 2:2 warning: unused attribute,
rust/rust/test.rs:1 #![foo]
rust/rust/test.rs:2 #![bar]
```
instead of
```
test.rs:1:1: 1:8 warning: unused attribute, #[warn(unused_attribute)] on
by default
test.rs:1 #![foo]
^~~~~~~
```
auto merge of #15601 : jbclements/rust/disable-default-macro-behavior, r=alexcrichton
Our AST definition can include macro invocations, which can expand into all kinds of things. Macro invocations are expanded away during expansion time, and the rest of the compiler doesn't have to deal with them. However, we have no way of enforcing this.
This patch adds two protective mechanisms.
First, it adds a (quick) explicit check that ensures there are no macro invocations remaining in the AST after expansion. Second, it updates the visit and fold mechanisms so that by default, they will not traverse macro invocations. It's easy enough to add this, if desired (it's documented in the source, and examples appear, e.g. in the IdentFinder.
Along the way, I also consulted with @sfackler to refactor the macro export mechanism so that it stores macro text spans in a side table, rather than leaving them in the AST.
auto merge of #15588 : alexcrichton/rust/issue-15478, r=cmr
If modified, you can safely unmap arbitrary memory. These fields are not
intended to be modified, so read-only accessors are the only ones that are
provided.
Alex Crichton [Thu, 10 Jul 2014 20:20:39 +0000 (13:20 -0700)]
std: Move MemoryMap fields to methods
If modified, you can safely unmap arbitrary memory. These fields are not
intended to be modified, so read-only accessors are the only ones that are
provided.
auto merge of #15597 : brson/rust/ldconfig, r=pcwalton
If ldconfig fails it emits a warning. This is very possible when installing
to a non-system directory, so the warning tries to indicate that it may
not be a problem.
auto merge of #15589 : Denommus/rust/master, r=alexcrichton
I have noticed some errors and some absences that I considered essential to the usability of rustc in zsh, so I included them and updated some of the man page.
Steven Fackler [Fri, 11 Jul 2014 22:26:26 +0000 (15:26 -0700)]
Fix spans for attributes
They used to be one token too long, so you'd see things like
```
rust/rust/test.rs:1:1: 2:2 warning: unused attribute,
rust/rust/test.rs:1 #![foo]
rust/rust/test.rs:2 #![bar]
```
instead of
```
test.rs:1:1: 1:8 warning: unused attribute, #[warn(unused_attribute)] on
by default
test.rs:1 #![foo]
^~~~~~~
```
projects / rust.git / log