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 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.
bors [Sun, 23 Aug 2015 15:41:34 +0000 (15:41 +0000)]
Auto merge of #27948 - wthrowe:f64-sqrt, r=alexcrichton
This fixes a reappearance of bug #9987 introduced in 1ddee8070d3cb83609b1f71c29e3deda3d30fd51, which caused
f64::tests::test_sqrt_domain to fail (at least on some systems).
Björn Steinbrink [Sun, 23 Aug 2015 13:27:25 +0000 (15:27 +0200)]
Improve codegen for the various "with overflow" intrinsics
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.
William Throwe [Sun, 23 Aug 2015 00:06:25 +0000 (20:06 -0400)]
Fix undefined behavior in f64::sqrt
This fixes a reappearance of bug #9987 introduced in 1ddee8070d3cb83609b1f71c29e3deda3d30fd51, which caused
f64::tests::test_sqrt_domain to fail (at least on some systems).
Steve Klabnik [Sat, 22 Aug 2015 23:15:43 +0000 (19:15 -0400)]
Rollup merge of #27926 - durka:emphasize-no-bin-doctest, r=steveklabnik
It came up twice in quick succession on IRC that rustdoc doesn't run tests in bin crates, and doesn't give any explanation/warning either as to why. I thought it couldn't hurt to emphasize that in the Book.
While going over various problems signaled by valgrind when running `make check` on a build configured with `--enable-valgrind`, I discovered a bug in this test case.
Namely, the test case was previously creating an `i32` (originally an `int` aka `isize` but then we changed the name and the fallback rules), and then reading from a `*const isize`. Valgrind rightly complains about this, since we are reading an 8 byte value on 64-bit systems, but in principle only 4 bytes have been initialized.
(I wish this was the only valgrind unclean test, but unfortunately there are a bunch more. This was just the easiest/first one that I dissected.)
bors [Sat, 22 Aug 2015 16:14:25 +0000 (16:14 +0000)]
Auto merge of #27913 - birkenfeld:remove_suffix_len, r=alexcrichton
The methods gave wrong results for TyIs and TyUs, whose suffix len
should be 5 nowadays. But since they were only used for parsing,
and unneeded for that since 606a309d, remove them rather than fixing.
I hope this is ok to do, since all of rustc is considered unstable...
bors [Sat, 22 Aug 2015 11:42:36 +0000 (11:42 +0000)]
Auto merge of #27892 - nikomatsakis:issue-27583, r=pnkfelix
Issue #27583 was caused by the fact that `LUB('a,'b)` yielded `'static`, even if there existed a region `'tcx:'a+'b`. This PR replaces the old very hacky code for computing how free regions relate to one another with something rather more robust. This solves the issue for #27583, though I think that similar bizarro bugs can no doubt arise in other ways -- the root of the problem is that the region-inference code was written in an era when a LUB always existed, but that hasn't held for some time. To *truly* solve this problem, it needs to be generalized to cope with that reality. But let's leave that battle for another day.
bors [Sat, 22 Aug 2015 09:59:07 +0000 (09:59 +0000)]
Auto merge of #27871 - alexcrichton:stabilize-libcore, r=aturon
These commits move libcore into a state so that it's ready for stabilization, performing some minor cleanup:
* The primitive modules for integers in the standard library were all removed from the source tree as they were just straight reexports of the libcore variants.
* The `core::atomic` module now lives in `core::sync::atomic`. The `core::sync` module is otherwise empty, but ripe for expansion!
* The `core::prelude::v1` module was stabilized after auditing that it is a subset of the standard library's prelude plus some primitive extension traits (char, str, and slice)
* Some unstable-hacks for float parsing errors were shifted around to not use the same unstable hacks (e.g. the `flt2dec` module is now used for "privacy").
After this commit, the remaining large unstable functionality specific to libcore is:
* `raw`, `intrinsics`, `nonzero`, `array`, `panicking`, `simd` -- these modules are all unstable or not reexported in the standard library, so they're just remaining in the same status quo as before
* `num::Float` - this extension trait for floats needs to be audited for functionality (much of that is happening in #27823) and may also want to be renamed to `FloatExt` or `F32Ext`/`F64Ext`.
* Should the extension traits for primitives be stabilized in libcore?
I believe other unstable pieces are not isolated to just libcore but also affect the standard library.
bors [Sat, 22 Aug 2015 06:30:53 +0000 (06:30 +0000)]
Auto merge of #27826 - sfackler:wait-timeout-enum, r=alexcrichton
Returning a primitive bool results in a somewhat confusing API - does
`true` indicate success - i.e. no timeout, or that a timeout has
occurred? An explicitly named enum makes it clearer.
bors [Fri, 21 Aug 2015 17:42:19 +0000 (17:42 +0000)]
Auto merge of #27613 - GSam:binop, r=nrc
In the case where there are no paren in the AST, the pretty printer doesn't correctly print binary operations where precedence is concerned. Parenthesis may be missing due to some kind of expansion or manipulation of the AST.
Example:
Pretty printer prints Expr(*, Expr(+, 1, 1), 2) as 1 + 1 * 2, as opposed to (1 + 1) * 2
bors [Fri, 21 Aug 2015 05:04:32 +0000 (05:04 +0000)]
Auto merge of #27837 - Gankro:weaknique, r=aturon
This prepares both for the FCP of #27718
Arc:
* Add previously omitted function `Arc::try_unwrap(Self) -> Result<T, Self>`
* Move `arc.downgrade()` to `Arc::downgrade(&Self)` per conventions.
* Deprecate `Arc::weak_count` and `Arc::strong_count` for raciness. It is almost
impossible to correctly act on these results without a CAS loop on the actual
fields.
* Rename `Arc::make_unique` to `Arc::make_mut` to avoid uniqueness terminology
and to clarify relation to `Arc::get_mut`.
Rc:
* Add `Rc::would_unwrap(&Self) -> bool` to introspect whether try_unwrap would succeed,
because it's destructive (unlike get_mut).
* Move `rc.downgrade()` to `Rc::downgrade(&Self)` per conventions.
* Deprecate `Rc::weak_count` and `Rc::strong_count` for questionable utility.
* Deprecate `Rc::is_unique` for questionable semantics (there are two kinds of
uniqueness with Weak pointers in play).
* Rename `rc.make_unique()` to `Rc::make_mut(&mut Self)` per conventions, to
avoid uniqueness terminology, and to clarify the relation to `Rc::get_mut`.
Notable omission:
* Arc::would_unwrap is not added due to the fact that it's racy, and therefore doesn't
provide much actionable information.
(note: rc_would_unwrap is not proposed for FCP as it is truly experimental)
r? @aturon (careful attention needs to be taken for the new Arc::try_unwrap, but intuitively it should "just work" by virtue of being semantically equivalent to Drop).
While going over various problems signaled by valgrind when running
`make check` on a build configured with `--enable-valgrind`, I
discovered a bug in this test case.
Namely, the test case was previously creating an `i32` (originally an
`int` aka `isize` but then we changed the name and the fallback
rules), and then reading from a `*const isize`. Valgrind rightly
complains about this, since we are reading an 8 byte value on 64-bit
systems, but in principle only 4 bytes have been initialized.
(I wish this was the only valgrind unclean test, but unfortunately
there are a bunch more. This was just the easiest/first one that I
dissected.)
Georg Brandl [Thu, 20 Aug 2015 05:23:15 +0000 (07:23 +0200)]
syntax: remove suffix_len methods from LitIntTypes
The methods gave wrong results for TyIs and TyUs, whose suffix len
should be 5 nowadays. But since they were only used for parsing,
and unneeded for that since 606a309d, remove them rather than fixing.
Steven Fackler [Fri, 14 Aug 2015 04:58:20 +0000 (21:58 -0700)]
Make Condvar::wait_timeout return an enum instead of a bool
Returning a primitive bool results in a somewhat confusing API - does
`true` indicate success - i.e. no timeout, or that a timeout has
occurred? An explicitly named enum makes it clearer.
* Add previously omitted function `Arc::try_unwrap(Self) -> Result<T, Self>`
* Move `arc.downgrade()` to `Arc::downgrade(&Self)` per conventions.
* Deprecate `Arc::weak_count` and `Arc::strong_count` for raciness. It is almost
impossible to correctly act on these results without a CAS loop on the actual
fields.
* Rename `Arc::make_unique` to `Arc::make_mut` to avoid uniqueness terminology
and to clarify relation to `Arc::get_mut`.
* Add `Rc::would_unwrap(&Self) -> bool` to introspect whether try_unwrap would succeed,
because it's destructive (unlike get_mut).
* Move `rc.downgrade()` to `Rc::downgrade(&Self)` per conventions.
* Deprecate `Rc::weak_count` and `Rc::strong_count` for questionable utility.
* Deprecate `Rc::is_unique` for questionable semantics (there are two kinds of
uniqueness with Weak pointers in play).
* Rename `rc.make_unique()` to `Rc::make_mut(&mut Self)` per conventions, to
avoid uniqueness terminology, and to clarify the relation to `Rc::get_mut`.
projects / rust.git / log