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]
^~~~~~~
```
John Clements [Wed, 9 Jul 2014 23:41:13 +0000 (16:41 -0700)]
add Macro Exterminator
the Macro Exterminator ensures that there are no macro invocations in
an AST. This should help make later passes confident that there aren't
hidden items, methods, expressions, etc.
John Clements [Wed, 9 Jul 2014 21:48:12 +0000 (14:48 -0700)]
make walk/visit_mac opt-in only
macros can expand into arbitrary items, exprs, etc. This
means that using a default walker or folder on an AST before
macro expansion is complete will miss things (the things that
the macros expand into). As a partial fence against this, this
commit moves the default traversal of macros into a separate
procedure, and makes the default trait implementation signal
an error. This means that Folders and Visitors can traverse
macros if they want to, but they need to explicitly add an
impl that calls the walk_mac or fold_mac procedure
John Clements [Thu, 10 Jul 2014 22:41:11 +0000 (15:41 -0700)]
use side table to store exported macros
Per discussion with @sfackler, refactored the expander to
change the way that exported macros are collected. Specifically,
a crate now contains a side table of spans that exported macros
go into.
This has two benefits. First, the encoder doesn't need to scan through
the expanded crate in order to discover exported macros. Second, the
expander can drop all expanded macros from the crate, with the pleasant
result that a fully expanded crate contains no macro invocations (which
include macro definitions).
auto merge of #15503 : pnkfelix/rust/fsk-linear-deriving-partialord, r=huonw
Instead of generating a separate case (albeit trivial) for each of the N*N cases when comparing two instances of an enum with N variants, this `deriving` uses the strategy outlined here: https://github.com/rust-lang/rust/issues/15375#issuecomment-47994007
In particular, it generates code that looks more like this:
```rust
match (this, that, ...) {
(Variant1, Variant1, Variant1) => ... // delegate Matching on Variant1
(Variant2, Variant2, Variant2) => ... // delegate Matching on Variant2
...
_ => {
let index_tup = {
let idx_this = match this { Variant1 => 0u, Variant2 => 1u, ... };
let idx_that = match that { Variant1 => 0u, Variant2 => 1u, ... };
...
(idx_this, idx_that, ...)
};
... // delegate to catch-all; it can inspect `index_tup` for its logic
}
}
```
While adding a new variant to the `const_nonmatching` flag (and renaming it to `on_nonmatching`) to allow expressing the above (while still allowing one to opt back into the old `O(N^2)` and in general `O(N^K)` (where `K` is the number of self arguments) code generation behavior), I had two realizations:
1. Observation: Nothing except for the comparison derivings (`PartialOrd`, `Ord`, `PartialEq`, `Eq`) were even using the old `O(N^K)` code generator. So after this hypothetically lands, *nothing* needs to use them, and thus that code generation strategy could be removed, under the assumption that it is very unlikely that any `deriving` mode will actually need that level of generality.
2. Observation: The new code generator I am adding can actually be unified with all of the other code generators that just dispatch on the variant tag (they all assume that there is only one self argument).
These two observations mean that one can get rid of the `const_nonmatching` (aka `on_nonmatching`) entirely. So I did that too in this PR.
The question is: Do we actually want to follow through on both of the above observations? I'm pretty sure the second observation is a pure win. But there *might* be someone out there with an example that invalidates the reasoning in the first observation. That is, there might be a client out there with an example of hypothetical deriving mode that wants to opt into the `O(N^K)` behavior. So, if that is true, then I can revise this PR to resurrect the `on_nonmatching` flag and provide a way to access the `O(N^K)` behavior.
The manner in which I choose to squash these commits during a post-review rebase depends on the answer to the above question.
Removed dead structures after changes to PartialOrd/Ord derivings.
Remove the `NonMatchesExplode` variant now that no deriving impl uses it.
Removed `EnumNonMatching` entirely.
Remove now irrelevant `on_matching` field and `HandleNonMatchingEnums` type.
Removed unused `EnumNonMatchFunc` type def.
Drive-by: revise `EnumNonMatchCollapsedFunc` doc.
Made all calls to `expand_enum_method_body` go directly to
`build_enum_match_tuple`.
Alpha-rename `enum_nonmatch_g` back to `enum_nonmatch_f` to reduce overall diff noise.
Inline sole call of `some_ordering_const`.
Inline sole call of `ordering_const`.
Removed a bunch of code that became dead after the above changes.
`O(n*k)` code-size deriving on enums (better than previous `O(n^k)`).
In the above formulas, `n` is the number of variants, and `k` is the
number of self-args fed into deriving. In the particular case of
interest (namely `PartialOrd` and `Ord`), `k` is always 2, so we are
basically comparing `O(n)` versus `O(n^2)`.
Also, the stage is set for having *all* enum deriving codes go through
`build_enum_match_tuple` and getting rid of `build_enum_match`.
Also, seriously attempted to clean up the code itself. Added a bunch
of comments attempting to document what I learned as I worked through
the original code and adapted it to this new strategy.
Revise the `const_nonmatching` flag with more info about author's intent.
In particular, I want authors of deriving modes to understand what
they are opting into (namely quadratic code size or worse) when they
select NonMatchesExplode.
auto merge of #15576 : mrmonday/rust/patch-1, r=alexcrichton
Add a couple of lines mentioning event_loop_factory - no clear error message is given if you attempt to perform I/O in tasks created in this fashion. I spent a many hours debugging this yesterday which would have been avoided if it were documented.
auto merge of #15575 : mvdnes/rust/spinlock_error, r=alexcrichton
The current example of a spinlock was not correct. The lock is actually acquired
when `old == result`. So we only need to deschedule when this is not the case.
Brian Anderson [Fri, 11 Jul 2014 01:25:50 +0000 (18:25 -0700)]
install: Run ldconfig when installing on Unix. Closes #15596.
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 #15336 : jakub-/rust/diagnostics, r=brson
This is a continuation of @brson's work from https://github.com/rust-lang/rust/pull/12144.
This implements the minimal scaffolding that allows mapping diagnostic messages to alpha-numeric codes, which could improve the searchability of errors. In addition, there's a new compiler option, `--explain {code}` which takes an error code and prints out a somewhat detailed explanation of the error. Example:
```shell
[~/rust]$ ./build/x86_64-apple-darwin/stage2/bin/rustc ./diagnostics.rs --crate-type dylib
diagnostics.rs:5:3: 5:13 error: unreachable pattern [E0001] (pass `--explain E0001` to see a detailed explanation)
diagnostics.rs:5 Some(true) => ()
^~~~~~~~~~
error: aborting due to previous error
[~/rust]$ ./build/x86_64-apple-darwin/stage2/bin/rustc --explain E0001
This error suggests that the expression arm corresponding to the noted pattern
will never be reached as for all possible values of the expression being matched,
one of the preceeding patterns will match.
This means that perhaps some of the preceeding patterns are too general, this
one is too specific or the ordering is incorrect.
```
I've refrained from migrating many errors to actually use the new macros as it can be done in an incremental fashion but if we're happy with the approach, it'd be good to do all of them sooner rather than later.
Originally, I was going to make libdiagnostics a separate crate but that's posing some interesting challenges with semi-circular dependencies. In particular, librustc would have a plugin-phase dependency on libdiagnostics, which itself depends on librustc. Per my conversation with @alexcrichton, it seems like the snapshotting process would also have to change. So for now the relevant modules from libdiagnostics are included using `#[path = ...] mod`.
auto merge of #15353 : aturon/rust/env-hashmap, r=alexcrichton
This commit adds `env_insert` and `env_remove` methods to the `Command`
builder, easing updates to the environment variables for the child
process. The existing method, `env`, is still available for overriding
the entire environment in one shot (after which the `env_insert` and
`env_remove` methods can be used to make further adjustments).
To support these new methods, the internal `env` representation for
`Command` has been changed to an optional `HashMap` holding owned
`CString`s (to support non-utf8 data). The `HashMap` is only
materialized if the environment is updated. The implementation does not
try hard to avoid allocation, since the cost of launching a process will
dwarf any allocation cost.
This patch also adds `PartialOrd`, `Eq`, and `Hash` implementations for
`CString`.
This commit changes the `io::process::Command` API to provide
fine-grained control over the environment:
* The `env` method now inserts/updates a key/value pair.
* The `env_remove` method removes a key from the environment.
* The old `env` method, which sets the entire environment in one shot,
is renamed to `env_set_all`. It can be used in conjunction with the
finer-grained methods. This renaming is a breaking change.
To support these new methods, the internal `env` representation for
`Command` has been changed to an optional `HashMap` holding owned
`CString`s (to support non-utf8 data). The `HashMap` is only
materialized if the environment is updated. The implementation does not
try hard to avoid allocation, since the cost of launching a process will
dwarf any allocation cost.
This patch also adds `PartialOrd`, `Eq`, and `Hash` implementations for
`CString`.
Alex Crichton [Thu, 10 Jul 2014 17:19:38 +0000 (10:19 -0700)]
rustc: Exclude #[repr(C)] from non camel case
C structs predominately do not use camel case identifiers, and we have a clear
indicator for what's a C struct now, so excuse all of them from this stylistic
lint.
The current example of a spinlock was not correct. The lock is actually acquired
when old == result. So we only need to deschedule when this is not the case.
projects / rust.git / log