bors [Mon, 7 Dec 2015 22:28:45 +0000 (22:28 +0000)]
Auto merge of #30087 - petrochenkov:indi, r=nrc
I've measured the time/memory consumption before and after - the difference is lost in statistical noise, so it's mostly a code simplification.
Sizes of `enum`s are not affected.
r? @nrc
I wonder if AST/HIR visitors could run faster if `P`s are systematically removed (except for cases where they control `enum` sizes). Theoretically they should.
Remaining unnecessary `P`s can't be easily removed because many folders accept `P<X>`s as arguments, but these folders can be converted to accept `X`s instead without loss of efficiency.
When I have a mood for some mindless refactoring again, I'll probably try to convert the folders, remove remaining `P`s and measure again.
This caused a regression such that types like `[[u8; 256]; 4]`
no longer implemented Clone. This previously worked due to Clone
for `[T; N]` (N in 0 to 32) being implemented for T: Copy.
Due to fixed size arrays not implementing Clone for sizes above 32,
the new implementation requiring T: Clone would not allow
`[[u8; 256]; 4]` to be Clone.
Fixes #30244
Due to changing back, this is technically a [breaking-change],
albeit for a behavior that existed for a very short time.
This caused a regression such that types like `[[u8; 256]; 4]`
no longer implemented Clone. This previously worked due to Clone
for `[T; N]` (N in 0 to 32) being implemented for T: Copy.
Due to fixed size arrays not implementing Clone for sizes above 32,
the new implementation requiring T: Clone would not allow
`[[u8; 256]; 4]` to be Clone.
bors [Sun, 6 Dec 2015 04:12:54 +0000 (04:12 +0000)]
Auto merge of #30187 - alexcrichton:stabilize-1.6, r=aturon
This commit is the standard API stabilization commit for the 1.6 release cycle.
The list of issues and APIs below have all been through their cycle-long FCP and
the libs team decisions are listed below
Stabilized APIs
* `Read::read_exact`
* `ErrorKind::UnexpectedEof` (renamed from `UnexpectedEOF`)
* libcore -- this was a bit of a nuanced stabilization, the crate itself is now
marked as `#[stable]` and the methods appearing via traits for primitives like
`char` and `str` are now also marked as stable. Note that the extension traits
themeselves are marked as unstable as they're imported via the prelude. The
`try!` macro was also moved from the standard library into libcore to have the
same interface. Otherwise the functions all have copied stability from the
standard library now.
* `fs::DirBuilder`
* `fs::DirBuilder::new`
* `fs::DirBuilder::recursive`
* `fs::DirBuilder::create`
* `os::unix::fs::DirBuilderExt`
* `os::unix::fs::DirBuilderExt::mode`
* `vec::Drain`
* `vec::Vec::drain`
* `string::Drain`
* `string::String::drain`
* `vec_deque::Drain`
* `vec_deque::VecDeque::drain`
* `collections::hash_map::Drain`
* `collections::hash_map::HashMap::drain`
* `collections::hash_set::Drain`
* `collections::hash_set::HashSet::drain`
* `collections::binary_heap::Drain`
* `collections::binary_heap::BinaryHeap::drain`
* `Vec::extend_from_slice` (renamed from `push_all`)
* `Mutex::get_mut`
* `Mutex::into_inner`
* `RwLock::get_mut`
* `RwLock::into_inner`
* `Iterator::min_by_key` (renamed from `min_by`)
* `Iterator::max_by_key` (renamed from `max_by`)
Alex Crichton [Thu, 3 Dec 2015 01:31:49 +0000 (17:31 -0800)]
std: Stabilize APIs for the 1.6 release
This commit is the standard API stabilization commit for the 1.6 release cycle.
The list of issues and APIs below have all been through their cycle-long FCP and
the libs team decisions are listed below
Stabilized APIs
* `Read::read_exact`
* `ErrorKind::UnexpectedEof` (renamed from `UnexpectedEOF`)
* libcore -- this was a bit of a nuanced stabilization, the crate itself is now
marked as `#[stable]` and the methods appearing via traits for primitives like
`char` and `str` are now also marked as stable. Note that the extension traits
themeselves are marked as unstable as they're imported via the prelude. The
`try!` macro was also moved from the standard library into libcore to have the
same interface. Otherwise the functions all have copied stability from the
standard library now.
* The `#![no_std]` attribute
* `fs::DirBuilder`
* `fs::DirBuilder::new`
* `fs::DirBuilder::recursive`
* `fs::DirBuilder::create`
* `os::unix::fs::DirBuilderExt`
* `os::unix::fs::DirBuilderExt::mode`
* `vec::Drain`
* `vec::Vec::drain`
* `string::Drain`
* `string::String::drain`
* `vec_deque::Drain`
* `vec_deque::VecDeque::drain`
* `collections::hash_map::Drain`
* `collections::hash_map::HashMap::drain`
* `collections::hash_set::Drain`
* `collections::hash_set::HashSet::drain`
* `collections::binary_heap::Drain`
* `collections::binary_heap::BinaryHeap::drain`
* `Vec::extend_from_slice` (renamed from `push_all`)
* `Mutex::get_mut`
* `Mutex::into_inner`
* `RwLock::get_mut`
* `RwLock::into_inner`
* `Iterator::min_by_key` (renamed from `min_by`)
* `Iterator::max_by_key` (renamed from `max_by`)
bors [Sat, 5 Dec 2015 09:08:14 +0000 (09:08 +0000)]
Auto merge of #30185 - fhahn:improve-borrowck-public-accessibility, r=pnkfelix
This PR makes `AnalysisData` and`BorrowckCtxt` public. Those types are returned by the public function `build_borrowck_dataflow_data_for_fn` and are needed if a caller wants to pass on the return values.
It also removes `FnPartsWithCFG`, which required callers of `build_borrowck_dataflow_data_for_fn` to have a reference to a `CFG` with the same lifetime as `FnParts`, which is more limiting than required.
bors [Fri, 4 Dec 2015 08:46:29 +0000 (08:46 +0000)]
Auto merge of #29850 - Kimundi:attributes_that_make_a_statement, r=pnkfelix
See https://github.com/rust-lang/rfcs/pull/16 and https://github.com/rust-lang/rust/issues/15701
- Added syntax support for attributes on expressions and all syntax nodes in statement position.
- Extended `#[cfg]` folder to allow removal of statements, and
of expressions in optional positions like expression lists and trailing
block expressions.
- Extended lint checker to recognize lint levels on expressions and
locals.
- As per RFC, attributes are not yet accepted on `if` expressions.
Examples:
```rust
let x = y;
{
...
}
assert_eq!((1, #[cfg(unset)] 2, 3), (1, 3));
let FOO = 0;
```
Implementation wise, there are a few rough corners and open questions:
- The parser work ended up a bit ugly.
- The pretty printer change was based mostly on guessing.
- Similar to the `if` case, there are some places in the grammar where a new `Expr` node starts,
but where it seemed weird to accept attributes and hence the parser doesn't. This includes:
- const expressions in patterns
- in the middle of an postfix operator chain (that is, after `.`, before indexing, before calls)
- on range expressions, since `#[attr] x .. y` parses as `(#[attr] x) .. y`, which is inconsistent with
`#[attr] .. y` which would parse as `#[attr] (.. y)`
- Attributes are added as additional `Option<Box<Vec<Attribute>>>` fields in expressions and locals.
- Memory impact has not been measured yet.
- A cfg-away trailing expression in a block does not currently promote the previous `StmtExpr` in a block to a new trailing expr. That is to say, this won't work:
```rust
let x = {
#[cfg(foo)]
Foo { data: x }
#[cfg(not(foo))]
Foo { data: y }
};
```
- One-element tuples can have their inner expression removed to become Unit, but just Parenthesis can't. Eg, `(#[cfg(unset)] x,) == ()` but `(#[cfg(unset)] x) == error`. This seemed reasonable to me since tuples and unit are type constructors, but could probably be argued either way.
- Attributes on macro nodes are currently unconditionally dropped during macro expansion, which seemed fine since macro disappear at that point?
- Attributes on `ast::ExprParens` will be prepend-ed to the inner expression in the hir folder.
- The work on pretty printer tests for this did trigger, but not fix errors regarding macros:
- expression `foo![]` prints as `foo!()`
- expression `foo!{}` prints as `foo!()`
- statement `foo![];` prints as `foo!();`
- statement `foo!{};` prints as `foo!();`
- statement `foo!{}` triggers a `None` unwrap ICE.
mitaa [Thu, 3 Dec 2015 22:11:19 +0000 (23:11 +0100)]
Use the extern item-path for documentation links
The local item-path includes the local crates path to the extern crate
declaration which breaks cross-crate rustdoc links if the extern crate
is not linked into the crate root or renamed via `extern foo as bar`.
Bryce Van Dyk [Mon, 23 Nov 2015 09:03:52 +0000 (22:03 +1300)]
libterm: bring across changes from term
This brings across changes made to the term library to libterm. This
includes removing instances or unwrap, fixing format string handling, and
removing a TODO.
This fix does not bring all changes across, as term now relies on cargo
deps that cannot be brought into the rust build at this stage, but has
attempted as best to cross port changes not relying on this. This notably
limits extra functionality since implemented int he Terminal trait in
Term.
This is in partly in response to rust issue #29992.
Steve Klabnik [Wed, 2 Dec 2015 00:01:42 +0000 (19:01 -0500)]
Rollup merge of #30153 - durka:patch-11, r=steveklabnik
I think this fixes #30137. I basically just repeated some details that were scattered around other places in this document, and emphasized that you probably don't want an `extern crate` or `mod` statement to end up inside a function.
Steve Klabnik [Wed, 2 Dec 2015 00:01:41 +0000 (19:01 -0500)]
Rollup merge of #30144 - pjungwir:clarify-semver-rules, r=steveklabnik
The documentation shows this:
[dependencies]
rand="0.3.0"
and says it allows any version compatible with 0.3.0, but then it says, "If we wanted to use only 0.3.0 exactly, we could use `=0.3.0`." That is very easy to misunderstand, so hopefully this PR will help others not to be as confused as me. :-)
projects / rust.git / log