bors [Wed, 26 Aug 2015 18:29:02 +0000 (18:29 +0000)]
Auto merge of #27992 - wthrowe:dead-main-2, r=alexcrichton
* Suppresses warnings that main is unused when testing (#12327)
* Makes `--test` work with explicit `#[start]` (#11766)
* Fixes some cases where the normal main would not be disabled by `--test`, resulting in compilation failures.
Cody P Schafer [Wed, 26 Aug 2015 15:21:36 +0000 (11:21 -0400)]
mk: tell rustc that we're only looking for native libs in the LLVM_LIBDIR
This fixes the case where we try to re-build & re-install rust to the
same prefix (without uninstalling) while using an llvm-root that is the
same as the prefix.
Without this, builds like that fail with:
'error: multiple dylib candidates for `std` found'
See https://github.com/jmesmon/meta-rust/issues/6 for some details.
bors [Wed, 26 Aug 2015 00:27:00 +0000 (00:27 +0000)]
Auto merge of #27991 - bluss:chain-rev, r=alexcrichton
Correct iterator adaptor Chain
The iterator protocol specifies that the iteration ends with the return
value `None` from `.next()` (or `.next_back()`) and it is unspecified
what further calls return. The chain adaptor must account for this in
its DoubleEndedIterator implementation.
It uses three states:
- Both `a` and `b` are valid
- Only the Front iterator (`a`) is valid
- Only the Back iterator (`b`) is valid
The fourth state (neither iterator is valid) only occurs after Chain has
returned None once, so we don't need to store this state.
Ulrik Sverdrup [Tue, 25 Aug 2015 01:56:35 +0000 (03:56 +0200)]
Correct iterator adaptor Chain
The iterator protocol specifies that the iteration ends with the return
value `None` from `.next()` (or `.next_back()`) and it is unspecified
what further calls return. The chain adaptor must account for this in
its DoubleEndedIterator implementation.
It uses three states:
- Both `a` and `b` are valid
- Only the Front iterator (`a`) is valid
- Only the Back iterator (`b`) is valid
The fourth state (neither iterator is valid) only occurs after Chain has
returned None once, so we don't need to store this state.
Björn Steinbrink [Tue, 25 Aug 2015 16:33:55 +0000 (18:33 +0200)]
Omit lifetime intrinsics for function arguments and similar top-level items
Function arguments are live for the whole function scope, so adding
lifetime intrinsics around them adds no value. The same is true for drop
hint allocas and everything else that goes directly through
lvalue_scratch_datum. So the easiest fix is to emit lifetime intrinsics
only for lvalue datums that are created in to_lvalue_datum_in_scope().
The reduces peak memory usage and LLVM times by about 1-4%, depending on
the crate.
Björn Steinbrink [Tue, 25 Aug 2015 16:24:16 +0000 (18:24 +0200)]
Separate lifetime starts from alloca()
Combining them seemed like a good idea at the time, but turns out that
handling lifetimes separately makes it somewhat easier to handle cases
where we don't want the intrinsics, and let's you see more easily where
the start/end pairs are.
Björn Steinbrink [Tue, 25 Aug 2015 16:11:15 +0000 (18:11 +0200)]
Turn some alloca_no_lifetime() calls into plain alloca() calls
The issues that the comments referred to were fixed before the PR even
landed but we never got around to remove the hack of skipping the
lifetime start.
bors [Tue, 25 Aug 2015 12:31:11 +0000 (12:31 +0000)]
Auto merge of #27986 - chris-morgan:reduce-string-extend-str-implementation, r=bluss
Reserving lower_bound bytes was just silly. It’d be perfectly reasonable
to have empty strings in the iterator, which could cause superfluous
reallocation of the string, or to have more than one byte per string,
which could cause additional reallocation (in practice it’ll balance
out). The added complexity of this logic is simply pointless, adding
a little bloat with no demonstrable advantage and slight disadvantage.
Barosl Lee [Sat, 22 Aug 2015 14:51:53 +0000 (23:51 +0900)]
Respect `--color` when printing early errors
Currently, `early_error` and `early_warn` in `librustc::session` always
use `ColorConfig::Auto`. Modify them to follow the color configuration
set by the `--color` option.
As colored output is also printed during the early stage, parsing the
`--color` option should be done as early as possible. However, there are
still some cases when the output needs to be colored before knowing the
exact color settings. In these cases, it will be defaulted to
`ColorConfig::Auto`, which is the same as before.
bors [Tue, 25 Aug 2015 01:10:55 +0000 (01:10 +0000)]
Auto merge of #27945 - Eljay:upgrade-hoedown, r=alexcrichton
Some hoedown FFI changes:
- `HOEDOWN_EXT_NO_INTRA_EMPHASIS` constant changed.
- Updated/tidied up all callback function signatures.
- All opaque data access has an additional layer of indirection for some reason (`hoedown_renderer_data`).
William Throwe [Mon, 24 Aug 2015 15:34:04 +0000 (11:34 -0400)]
Move main removal to its own pass in --test mode
This handles the case where the #[main] function is buried deeper in
the ast than we search for #[test] functions. I'm not sure why one
would want to do that, but since it works in standard compilation it
should also work for tests.
bors [Mon, 24 Aug 2015 22:13:45 +0000 (22:13 +0000)]
Auto merge of #27943 - arielb1:fast-region, r=nikomatsakis
This increases regionck performance greatly - type-checking on
librustc decreased from 9.1s to 8.1s. Because of Amdahl's law,
total performance is improved only by about 1.5% (LLVM wizards,
this is your opportunity to shine!).
I am somewhat worried really need to find out why we have this Red Queen's
Race going on here. Originally I suspected it may be a problem from RFC1214's
warnings, but it seems to be an effect from other changes.
However, the increase seems to be mostly in LLVM's time, so I guess
it's the LLVM wizards' problem.
Chris Morgan [Mon, 24 Aug 2015 21:47:42 +0000 (07:47 +1000)]
Simplify `String`’s `Extend<&str>` implementation
Reserving lower_bound bytes was just silly. It’d be perfectly reasonable
to have empty strings in the iterator, which could cause superfluous
reallocation of the string, or to have more than one byte per string,
which could cause additional reallocation (in practice it’ll balance
out). The added complexity of this logic is simply pointless, adding
a little bloat with no demonstrable advantage and slight disadvantage.
Björn Steinbrink [Mon, 24 Aug 2015 19:50:50 +0000 (21:50 +0200)]
Rename get_len() to get_meta()
The functions is useful for all kinds of fat pointers, but get_len()
just feels so wrong for trait object fat pointers. Let's use get_meta()
because that's rather neutral.
Ariel Ben-Yehuda [Wed, 19 Aug 2015 22:46:28 +0000 (01:46 +0300)]
Use a Vec instead of an HashMap for the scope hierarchy
This increases regionck performance greatly - type-checking on
librustc decreased from 9.1s to 8.1s. Because of Amdahl's law,
total performance is improved only by about 1.5% (LLVM wizards,
this is your opportunity to shine!).
I am somewhat worried really need to find out why we have this Red Queen's
Race going on here. Originally I suspected it may be a problem from RFC1214's
warnings, but it seems to be an effect from other changes.
However, the increase seems to be mostly in LLVM's time, so I guess
it's the LLVM wizards' problem.
Andrea Canciani [Mon, 24 Aug 2015 15:47:01 +0000 (17:47 +0200)]
Minimize the implementation of `Rem` in libcore
The implementation of the remainder operation belongs to
librustc_trans, but it is also stubbed out in libcore in order to
expose it as a trait on primitive types. Instead of exposing some
implementation details (like the upcast to `f64` in MSVC), use a
minimal implementation just like that of the `Div` trait.
bors [Mon, 24 Aug 2015 12:47:57 +0000 (12:47 +0000)]
Auto merge of #27857 - Manishearth:improve-fnkind, r=pnkfelix
Since enums are namespaced now, should we also remove the `Fk` prefixes from `FnKind` and remove the reexport? (The reexport must be removed because otherwise it clashes with glob imports containing `ItemFn`). IMO writing `FnKind::Method` is much clearer than `FkMethod`.
bors [Mon, 24 Aug 2015 10:03:48 +0000 (10:03 +0000)]
Auto merge of #27856 - nikomatsakis:move-def-id-to-rustc, r=eddyb
It doesn't really make sense for DefId to be in libsyntax -- it is concerned with a single crate only. It is the compiler that understands the idea of many crates. (At some point, there might be a useful intermediate point here.) This is a refactoring in support of incr. compilation, which will be adjusting the notion of a DefId to make it more durable across compilations.
This will probably be a [breaking-change] for every plugin ever. You need to adjust things as follows:
use rustc::middle::def_id::{DefId, LOCAL_CRATE}; // two most common definitions
ast_util::is_local(def_id) => def_id.is_local()
ast_util::local_def(node_id) => DefId::local(node_id)
bors [Sun, 23 Aug 2015 21:45:29 +0000 (21:45 +0000)]
Auto merge of #27962 - dotdash:overflow, r=alexcrichton
We're currently possibly introducing an unneeded temporary, make use of
InsertValue which is said to kick us off of FastISel and we generate
loads/stores of first class aggregates, which is bad as well. Let's not
do all these things.