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.
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`.
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.
auto merge of #15561 : huonw/rust/must-use-iterators, r=alexcrichton
Similar to the stability attributes, a type annotated with `#[must_use =
"informative snippet"]` will print the normal warning message along with
"informative snippet". This allows the type author to provide some
guidance about why the type should be used.
---
It can be a little unintuitive that something like `v.iter().map(|x|
println!("{}", x));` does nothing: the majority of the iterator adaptors
are lazy and do not execute anything until something calls `next`, e.g.
a `for` loop, `collect`, `fold`, etc.
The majority of such errors can be seen by someone writing something
like the above, i.e. just calling an iterator adaptor and doing nothing
with it (and doing this is certainly useless), so we can co-opt the
`must_use` lint, using the message functionality to give a hint to the
reason why.
auto merge of #15550 : alexcrichton/rust/install-script, r=brson
This adds detection of the relevant LD_LIBRARY_PATH-like environment variable
and appropriately sets it when testing whether binaries can run or not.
Additionally, the installation prints a recommended value if one is necessary.
Huon Wilson [Wed, 9 Jul 2014 12:13:14 +0000 (22:13 +1000)]
core: add `#[must_use]` attributes to iterator adaptor structs.
It can be a little unintuitive that something like `v.iter().map(|x|
println!("{}", x));` does nothing: the majority of the iterator adaptors
are lazy and do not execute anything until something calls `next`, e.g.
a `for` loop, `collect`, `fold`, etc.
The majority of such errors can be seen by someone writing something
like the above, i.e. just calling an iterator adaptor and doing nothing
with it (and doing this is certainly useless), so we can co-opt the
`must_use` lint, using the message functionality to give a hint to the
reason why.
Huon Wilson [Wed, 9 Jul 2014 12:02:19 +0000 (22:02 +1000)]
lint: extend `#[must_use]` to handle a message.
Similar to the stability attributes, a type annotated with `#[must_use =
"informative snippet"]` will print the normal warning message along with
"informative snippet". This allows the type author to provide some
guidance about why the type should be used.
auto merge of #15471 : erickt/rust/push_all, r=acrichto
llvm is currently not able to conver `Vec::extend` into a memcpy for `Copy` types, which results in methods like `Vec::push_all` to run twice as slow as it should be running. This patch takes the unsafe `Vec::clone` optimization to speed up all the operations that are cloning a slice into a `Vec`.
auto merge of #15283 : kwantam/rust/master, r=alexcrichton
Add libunicode; move unicode functions from core
- created new crate, libunicode, below libstd
- split `Char` trait into `Char` (libcore) and `UnicodeChar` (libunicode)
- Unicode-aware functions now live in libunicode
- `is_alphabetic`, `is_XID_start`, `is_XID_continue`, `is_lowercase`,
`is_uppercase`, `is_whitespace`, `is_alphanumeric`, `is_control`, `is_digit`,
`to_uppercase`, `to_lowercase`
- added `width` method in UnicodeChar trait
- determines printed width of character in columns, or None if it is a non-NULL control character
- takes a boolean argument indicating whether the present context is CJK or not (characters with 'A'mbiguous widths are double-wide in CJK contexts, single-wide otherwise)
- split `StrSlice` into `StrSlice` (libcore) and `UnicodeStrSlice` (libunicode)
- functionality formerly in `StrSlice` that relied upon Unicode functionality from `Char` is now in `UnicodeStrSlice`
- `words`, `is_whitespace`, `is_alphanumeric`, `trim`, `trim_left`, `trim_right`
- also moved `Words` type alias into libunicode because `words` method is in `UnicodeStrSlice`
- unified Unicode tables from libcollections, libcore, and libregex into libunicode
- updated `unicode.py` in `src/etc` to generate aforementioned tables
- generated new tables based on latest Unicode data
- added `UnicodeChar` and `UnicodeStrSlice` traits to prelude
- libunicode is now the collection point for the `std::char` module, combining the libunicode functionality with the `Char` functionality from libcore
- thus, moved doc comment for `char` from `core::char` to `unicode::char`
- libcollections remains the collection point for `std::str`
The Unicode-aware functions that previously lived in the `Char` and `StrSlice` traits are no longer available to programs that only use libcore. To regain use of these methods, include the libunicode crate and `use` the `UnicodeChar` and/or `UnicodeStrSlice` traits:
extern crate unicode;
use unicode::UnicodeChar;
use unicode::UnicodeStrSlice;
use unicode::Words; // if you want to use the words() method
NOTE: this does *not* impact programs that use libstd, since UnicodeChar and UnicodeStrSlice have been added to the prelude.
auto merge of #15220 : vhbit/rust/treemap-str-equiv, r=alexcrichton
- it allows to lookup using any str-equiv object, making TreeMaps finally usable (for example, it is much easier to work with JSON with lookup values being static strs)
- actually provides pretty flexible solution which could be extended to other equivalent types (although it might be not that performant)
Alex Crichton [Wed, 9 Jul 2014 14:44:49 +0000 (07:44 -0700)]
etc: Fix install script for rpath removal
This adds detection of the relevant LD_LIBRARY_PATH-like environment variable
and appropriately sets it when testing whether binaries can run or not.
Additionally, the installation prints a recommended value if one is necessary.
- unicode tests live in coretest crate
- libcollections str tests need UnicodeChar trait.
- libregex perlw tests were checking a char in the Alphabetic category,
\x2161. Confirmed perl 5.18 considers this a \w character. Changed to
\x2961, which is not \w as the test expects.
auto merge of #15540 : Gankro/rust/master, r=huonw
Removing recursion from TreeMap implementation, because we don't have TCO. No need to add ```O(logn)``` extra stack frames to search in a tree.
I find it curious that ```find_mut``` and ```find``` basically duplicated the same logic, but in different ways (iterative vs recursive), possibly to maneuvre around mutability rules, but that's a more fundamental issue to deal with elsewhere.
Thanks to acrichto for the magic trick to appease borrowck (another issue to deal with elsewhere).
auto merge of #15530 : adrientetar/rust/proper-fonts, r=alexcrichton
- Treat WOFF as binary files so that git does not perform newline normalization.
- Replace corrupt Heuristica files with Source Serif Pro — italics are [almost in production](https://github.com/adobe/source-serif-pro/issues/2) so I left Heuristica Italic which makes a good pair with SSP. Overall, Source Serif Pro is I think a better fit for rustdoc (cc @TheHydroImpulse). This ought to fix #15527.
- Store Source Code Pro locally in order to make offline docs freestanding. Fixes #14778.
lexer: lex WS/COMMENT/SHEBANG rather than skipping
Now, the lexer will categorize every byte in its input according to the
grammar. The parser skips over these while parsing, thus avoiding their
presence in the input to syntax extensions.
Corey Richardson [Wed, 18 Jun 2014 17:44:20 +0000 (10:44 -0700)]
syntax: don't parse numeric literals in the lexer
This removes a bunch of token types. Tokens now store the original, unaltered
numeric literal (that is still checked for correctness), which is parsed into
an actual number later, as needed, when creating the AST.
This can change how syntax extensions work, but otherwise poses no visible
changes.
syntax: don't process string/char/byte/binary lits
This shuffles things around a bit so that LIT_CHAR and co store an Ident
which is the original, unaltered literal in the source. When creating the AST,
unescape and postprocess them.
This changes how syntax extensions can work, slightly, but otherwise poses no
visible changes. To get a useful value out of one of these tokens, call
`parse::{char_lit, byte_lit, bin_lit, str_lit}`
Corey Richardson [Tue, 17 Jun 2014 06:00:49 +0000 (23:00 -0700)]
syntax: use a better Show impl for Ident
Rather than just dumping the id in the interner, which is useless, actually
print the interned string. Adjust the lexer logging to use Show instead of
Poly.
projects / rust.git / log