bors [Fri, 11 Dec 2015 08:12:41 +0000 (08:12 +0000)]
Auto merge of #30265 - oli-obk:const_val_trans, r=pnkfelix
r? @nagisa
I'm going to need the `ConstVal` -> `ValueRef` translation to start removing trans/consts piece by piece. If you need anything implemented in the translation, feel free to assign an issue to me.
bors [Fri, 11 Dec 2015 06:29:06 +0000 (06:29 +0000)]
Auto merge of #30248 - petevine:master, r=brson
Running `/usr/bin/time -v make` to build rust (using local llvm) shows the maximum memory usage at 715 megabytes on 32-bit x86 (on arm linux it's even less @ 580M).
Reworded according to @brson's [input](https://github.com/rust-lang/rust/pull/30196#issuecomment-162088921).
bors [Fri, 11 Dec 2015 04:27:53 +0000 (04:27 +0000)]
Auto merge of #30294 - jseyfried:fix_shadowed_use_visibility, r=nrc
This fixes a bug in which the visibility of a use declaration defining a name in one namespace (e.g. the value namespace) is overridden by a later use declaration defining the same name in the other namespace (e.g. the type namespace). For example,
```rust
fn f() {}
pub mod bar {}
mod foo {
use f; // This import should not be visible outside `foo`,
pub use bar as f; // but it visible outside of `foo` because of this import.
}
fn main() { foo::f(); }
```
As the example demonstrates, this is a [breaking-change], but it looks unlikely to cause breakage in practice, and any breakage can be fixed by correcting visibility modifiers.
bors [Fri, 11 Dec 2015 00:59:48 +0000 (00:59 +0000)]
Auto merge of #30301 - michaelwoerister:mir-to-metadata2, r=nikomatsakis
This PR makes `Mir` `RustcEncodable` and `RustcDecodable` and stores it in crate metadata for inlinable items.
Some other things in here:
- `mir::visit::Visitor` is extended to also visit `Literals`, `Spans` and `DefIds`.
- It also adds `mir::visit::MutVisitor` which allows to mutate the visited `Mir` structure in place.
- Some numbers on how big MIR is in metadata (total metadata size in bytes):
So, adding MIR to metadata makes it about 25% bigger. It could be worse, considering that it still uses the inefficient RBML encoding. Still, the question is whether we should put MIR emission behind a `-Z` flag.
bors [Thu, 10 Dec 2015 21:36:08 +0000 (21:36 +0000)]
Auto merge of #30303 - mitaa:htmldocck, r=brson
This changes the error output and behaviour to:
* not emit python backtraces
* run all checks
* include a context line per error
* move the offending line-number to the start of the line
bors [Thu, 10 Dec 2015 19:54:15 +0000 (19:54 +0000)]
Auto merge of #30182 - alexcrichton:remove-deprecated, r=aturon
This is a standard "clean out libstd" commit which removes all 1.5-and-before
deprecated functionality as it's now all been deprecated for at least one entire
cycle.
Alex Crichton [Thu, 3 Dec 2015 01:07:29 +0000 (17:07 -0800)]
std: Remove deprecated functionality from 1.5
This is a standard "clean out libstd" commit which removes all 1.5-and-before
deprecated functionality as it's now all been deprecated for at least one entire
cycle.
bors [Thu, 10 Dec 2015 06:38:06 +0000 (06:38 +0000)]
Auto merge of #30293 - steveklabnik:fixes, r=brson
I meant to double check the work in https://github.com/rust-lang/rust/issues/29429, but due to Mozlando, forgot. Here are two small fixes.
r? @brson I would like to get this backported to beta as well, sorry :( I don't generally want doc backports, but feel this is exceptional and worth it.
Fix a bug in which the visibility of a use declaration defining a name in one namespace (e.g. the value namespace) is overridden by a later use declaration defining the same name in the other namespace (e.g. the type namespace).
bors [Wed, 9 Dec 2015 16:57:46 +0000 (16:57 +0000)]
Auto merge of #29937 - alexcrichton:panic-recover, r=alexcrichton
This commit is an implementation of [RFC 1236] and [RFC 1323] which
rename the `thread::catch_panic` function to `panic::recover` while also
replacing the `Send + 'static` bounds with a new `PanicSafe` bound.
Alex Crichton [Mon, 31 Aug 2015 15:51:53 +0000 (08:51 -0700)]
std: Rename thread::catch_panic to panic::recover
This commit is an implementation of [RFC 1236] and [RFC 1323] which
rename the `thread::catch_panic` function to `panic::recover` while also
replacing the `Send + 'static` bounds with a new `PanicSafe` bound.
bors [Wed, 9 Dec 2015 15:10:37 +0000 (15:10 +0000)]
Auto merge of #30140 - michaelwoerister:tls-encoding, r=nikomatsakis
With this commit, metadata encoding and decoding can make use of thread-local encoding and decoding contexts. These allow implementers of `serialize::Encodable` and `Decodable` to access information and
datastructures that would otherwise not be available to them. For example, we can automatically translate def-id and span information during decoding because the decoding context knows which crate the data is decoded from. Or it allows to make `ty::Ty` decodable because the context has access to the `ty::ctxt` that is needed for creating `ty::Ty` instances.
Some notes:
- `tls::with_encoding_context()` and `tls::with_decoding_context()` (as opposed to their unsafe versions) try to prevent the TLS data getting out-of-sync by making sure that the encoder/decoder passed in is actually the same as the one stored in the context. This should prevent accidentally reading from the wrong decoder.
- There are no real tests in this PR. I had a unit tests for some of the core aspects of the TLS implementation but it was kind of brittle, a lot of code for mocking `ty::ctxt`, `crate_metadata`, etc and did actually test not so much. The code will soon be tested by the first incremental compilation auto-tests that rely on MIR being properly serialized. However, if people think that some tests should be added before this can land, I'll try to provide some that make sense.
Add scoped thread-local encoding and decoding contexts to cstore.
With this commit, metadata encoding and decoding can make use of
thread-local encoding and decoding contexts. These allow implementers
of serialize::Encodable and Decodable to access information and
datastructures that would otherwise not be available to them. For
example, we can automatically translate def-id and span information
during decoding because the decoding context knows which crate the
data is decoded from. Or it allows to make ty::Ty decodable because
the context has access to the ty::ctxt that is needed for creating
ty::Ty instances.
bors [Wed, 9 Dec 2015 04:22:05 +0000 (04:22 +0000)]
Auto merge of #30245 - Aatch:dynamic-align-dst, r=pnkfelix
Fixes #26403
This adjusts the pointer, if needed, to the correct alignment by using the alignment information in the vtable.
Handling zero might not be necessary, as it shouldn't actually occur. I've left it as it's own commit so it can be removed fairly easily if people don't think it's worth doing. The way it's handled though means that there shouldn't be much impact on performance.
bors [Wed, 9 Dec 2015 02:38:57 +0000 (02:38 +0000)]
Auto merge of #30208 - pnkfelix:fix-issue-30063, r=alexcrichton
When given `rustc -C codegen-units=4 --emit=obj`, reset units back to 1.
Fix #30063
Note: while this code is careful to handle the case of mutliple emit types (e.g. `--emit=asm,obj`) by reporting all the emit types that conflict with codegen units in its warnings, an invocation with multiple emit types *and* `-o PATH` will continue to ignore the requested target path (with a warning), as it already does today, since the code that checks for that is further downstream. (Multiple emit types without `-o PATH` will "work", though it will downgrade codegen-units to 1 just like all the other cases.)
bors [Wed, 9 Dec 2015 00:41:26 +0000 (00:41 +0000)]
Auto merge of #30145 - petrochenkov:hyg, r=nrc
Instead of `ast::Ident`, bindings, paths and labels in HIR now keep a new structure called `hir::Ident` containing mtwt-renamed `name` and the original not-renamed `unhygienic_name`. `name` is supposed to be used by default, `unhygienic_name` is rarely used.
This is not ideal, but better than the status quo for two reasons:
- MTWT tables can be cleared immediately after lowering to HIR
- This is less bug-prone, because it is impossible now to forget applying `mtwt::resolve` to a name. It is still possible to use `name` instead of `unhygienic_name` by mistake, but `unhygienic_name`s are used only in few very special circumstances, so it shouldn't be a problem.
Besides name resolution `unhygienic_name` is used in some lints and debuginfo. `unhygienic_name` can be very well approximated by "reverse renaming" `token::intern(name.as_str())` or even plain string `name.as_str()`, except that it would break gensyms like `iter` in desugared `for` loops. This approximation is likely good enough for lints and debuginfo, but not for name resolution, unfortunately (see https://github.com/rust-lang/rust/issues/27639), so `unhygienic_name` has to be kept.
When given `rustc -C codegen-units=4 -o output --emit=obj`, reset units back to 1.
Fix #30063
Note: while this code is careful to handle the case of mutliple emit
types (e.g. `--emit=asm,obj`) by reporting all the emit types that
conflict with codegen units in its warnings, an invocation with
multiple emit types *and* `-o PATH` will continue to ignore the
requested target path (with a warning), as it already does today,
since the code that checks for that is further downstream.
James Miller [Tue, 8 Dec 2015 02:40:25 +0000 (15:40 +1300)]
Fix unsized structs with destructors
The presence of the drop flag caused the offset calculation to be
incorrect, leading to the pointer being incorrect. This has been fixed
by calculating the offset based on the field index (and not assuming
that the field is always the last one).
However, I've also stopped the drop flag from being added to the end of
unsized structs to begin with. Since it's not actually accessed for
unsized structs, and isn't actually where we would say it is, this made
more sense.
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.
James Miller [Sun, 6 Dec 2015 13:38:29 +0000 (02:38 +1300)]
Align pointers to DST fields properly
DST fields, being of an unknown type, are not automatically aligned
properly, so a pointer to the field needs to be aligned using the
information in the vtable.
Fixes #26403 and a number of other DST-related bugs discovered while
implementing this.
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.
petevine [Mon, 7 Dec 2015 00:12:53 +0000 (01:12 +0100)]
README.md - RAM requirement on 32-bit *nix
Running `/usr/bin/time -v make` to build rust (using local llvm) shows the maximum memory usage at 715 megabytes on 32-bit x86 (on arm linux it's even less @ 580M).
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`)
projects / rust.git / log