- 05 3月, 2015 4 次提交
-
-
由 Huon Wilson 提交于
-
由 Huon Wilson 提交于
This destabilises all the implementation details of `thread_local!`, since they do not *need* to be stable with the new attribute.
-
由 Huon Wilson 提交于
Unstable items used in a macro expansion will now always trigger stability warnings, *unless* the unstable items are directly inside a macro marked with `#[allow_internal_unstable]`. IOW, the compiler warns unless the span of the unstable item is a subspan of the definition of a macro marked with that attribute. E.g. #[allow_internal_unstable] macro_rules! foo { ($e: expr) => {{ $e; unstable(); // no warning only_called_by_foo!(); }} } macro_rules! only_called_by_foo { () => { unstable() } // warning } foo!(unstable()) // warning The unstable inside `foo` is fine, due to the attribute. But the `unstable` inside `only_called_by_foo` is not, since that macro doesn't have the attribute, and the `unstable` passed into `foo` is also not fine since it isn't contained in the macro itself (that is, even though it is only used directly in the macro). In the process this makes the stability tracking much more precise, e.g. previously `println!("{}", unstable())` got no warning, but now it does. As such, this is a bug fix that may cause [breaking-change]s. The attribute is definitely feature gated, since it explicitly allows side-stepping the feature gating system.
-
由 Alex Crichton 提交于
This commit deprecates the majority of std::old_io::fs in favor of std::fs and its new functionality. Some functions remain non-deprecated but are now behind a feature gate called `old_fs`. These functions will be deprecated once suitable replacements have been implemented. The compiler has been migrated to new `std::fs` and `std::path` APIs where appropriate as part of this change.
-
- 04 3月, 2015 6 次提交
-
-
由 Piotr Czarnecki 提交于
-
由 Michael Woerister 提交于
This allows to create proper debuginfo line information for items inlined from other crates (e.g. instantiations of generics). Only the codemap's 'metadata' is stored in a crate's metadata. That is, just filename, line-beginnings, etc. but not the actual source code itself. We are thus missing the opportunity of making Rust the first "open-source-only" programming language out there. Pity.
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
Many of the modifications putting in `Box::new` calls also include a pointer to Issue 22405, which tracks going back to `box <expr>` if possible in the future. (Still tried to use `Box<_>` where it sufficed; thus some tests still have `box_syntax` enabled, as they use a mix of `box` and `Box::new`.) Precursor for overloaded-`box` and placement-`in`; see Issue 22181.
-
由 Felix S. Klock II 提交于
(You shouldn't use it, but it is a semi-reasonable way to annotate types when necessary.)
-
由 Felix S. Klock II 提交于
This is the kind of change that one is expected to need to make to accommodate overloaded-`box`. ---- Note that this is not *all* of the changes necessary to accommodate Issue 22181. It is merely the subset of those cases where there was already a let-binding in place that made it easy to add the necesasry type ascription. (For unnamed intermediate `Box` values, one must go down a different route; `Box::new` is the option that maximizes portability, but has potential inefficiency depending on whether the call is inlined.) ---- There is one place worth note, `run-pass/coerce-match.rs`, where I used an ugly form of `Box<_>` type ascription where I would have preferred to use `Box::new` to accommodate overloaded-`box`. I deliberately did not use `Box::new` here, because that is already done in coerce-match-calls.rs. ---- Precursor for overloaded-`box` and placement-`in`; see Issue 22181.
-
- 03 3月, 2015 30 次提交
-
-
由 Felix S. Klock II 提交于
See buildlog here for evidence of such occurring: http://buildbot.rust-lang.org/builders/auto-linux-32-opt/builds/3910/steps/test/logs/stdio
-
由 Tobias Bucher 提交于
Conflicts: src/libstd/thread.rs
-
由 Manish Goregaokar 提交于
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
Suggestion was here: https://github.com/rust-lang/rust/pull/22532#discussion_r25505609
-
由 Felix S. Klock II 提交于
Added pair of regression tests that I should have made when I thought of doing this in the first place.
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
However, I left the ICEs rather than switching to nicer error reporting there; these cases *should* be detected prior to hitting trans, and thus ICE'ing here is appropriate. (So why switch to `eval_const_expr_partial`? Because I want to try to eliminate all uses of `eval_const_expr` entirely.)
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
1. Detect and report arithmetic overflow during const-expr eval. 2. Instead `eval_const_expr_partial` returning `Err(String)`, it now has a dedicated enum of different cases. The main benefit of this is the ability to pass along an interpretable payload, namely the two inputs that caused an overlfow. I attempted to minimize fallout to error output in tests, but some was unavoidable. Those changes are in a follow-on commit.
-
由 Felix S. Klock II 提交于
This allows computation to proceed and find further errors. (However, this is also annoying at times when the subsequent errors are just reporting that a ty_err occurred. I have thoughts on ways to fix this that I will experiment with separately.)
-
由 Felix S. Klock II 提交于
This only replaces the conditional arith-overflow asserts with unconditional errors from the guts of const-eval; it does *not* attempt to sanely handle such errors e.g. with a nice error message from `rustc`. So the same test that led me to add this commit are still failing, and must be addressed.
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
(The bug was in `impl RandomAccessIterator for Rev`; it may or may not have been innocuous, depending on what guarantees one has about the behavior of `idx` for the underlying iterator.)
-
由 Felix S. Klock II 提交于
Regarding the `rand` changes: It is unfortunate that Wrapping(T) does not support the `+=` operator. We may want to try to fix that before 1.0 to make porting code like this palatable. Regarding `std::rand`, just arith-overflow in first example from `std::rand::random()` doc.
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
* `core::num`: adjust `UnsignedInt::is_power_of_two`, `UnsignedInt::next_power_of_two`, `Int::pow`. In particular for `Int::pow`: (1.) do not panic when `base` overflows if `acc` never observes the overflowed `base`, and (2.) if `acc` does observe the overflowed `base`, make sure we only panic if we would have otherwise (e.g. during a computation of `base * base`). * also in `core::num`: avoid underflow during computation of `uint::MAX`. * `std::num`: adjust tests `uint::test_uint_from_str_overflow`, `uint::test_uint_to_str_overflow`, `strconv` * `coretest::num`: adjust `test::test_int_from_str_overflow`.
-
由 Felix S. Klock II 提交于
* The error patterns had a typo. * Our current constant evaluation would silently allow the overflow (filed as Issue 22531). * The overflowing-mul test was accidentally doing addition instead of multiplication.
-
由 Felix S. Klock II 提交于
* `collections::btree::node`: accommodate (transient) underflow. * `collections::btree::map`: avoid underflow during `fn next` for `BTreeMap::range` methods. * `collections::slice`: note that pnkfelix deliberately used `new_pos_wrapping` only once; the other cases of arithmetic do not over- nor underflow, which is a useful property to leave implicitly checked/documented via the remaining calls to `fn new_pos(..)`. * `collections::vec_deque` applied wrapping ops (somewhat blindly) to two implementation methods, and many tests. * `std::collections::hash::table` : Use `OverflowingOps` trait to track overflow during `calculate_offsets` and `calculate_allocation` functions.
-
由 Niko Matsakis 提交于
-
由 Felix S. Klock II 提交于
-
由 Felix S. Klock II 提交于
These return the result of the operation *plus* an overflow/underflow bit. This can make it easier to write operations where you want to chain some arithmetic together, but also want to return a flag signalling if overflow every occurred.
-
由 James Miller 提交于
During my clean-up of rebase errors, I took the opportunity to implement parse_opt_bool so that it isn't identical to parse_bool wrapped in `Some`. parse_opt_bool considers no value to be true, a value of 'y', 'yes' or 'on' to be true and 'n', 'no' or 'off' to be false. All other values are an error.
-
由 James Miller 提交于
Many of the core rust libraries have places that rely on integer wrapping behaviour. These places have been altered to use the wrapping_* methods: * core::hash::sip - A number of macros * core::str - The `maximal_suffix` method in `TwoWaySearcher` * rustc::util::nodemap - Implementation of FnvHash * rustc_back::sha2 - A number of macros and other places * rand::isaac - Isaac64Rng, changed to use the Wrapping helper type Some places had "benign" underflow. This is when underflow or overflow occurs, but the unspecified value is not used due to other conditions. * collections::bit::Bitv - underflow when `self.nbits` is zero. * collections::hash::{map,table} - Underflow when searching an empty table. Did cause undefined behaviour in this case due to an out-of-bounds ptr::offset based on the underflowed index. However the resulting pointers would never be read from. * syntax::ext::deriving::encodable - Underflow when calculating the index of the last field in a variant with no fields. These cases were altered to avoid the underflow, often by moving the underflowing operation to a place where underflow could not happen. There was one case that relied on the fact that unsigned arithmetic and two's complement arithmetic are identical with wrapping semantics. This was changed to use the wrapping_* methods. Finally, the calculation of variant discriminants could overflow if the preceeding discriminant was `U64_MAX`. The logic in `rustc::middle::ty` for this was altered to avoid the overflow completely, while the remaining places were changed to use wrapping methods. This is because `rustc::middle::ty::enum_variants` now throws an error when the calculated discriminant value overflows a `u64`. This behaviour can be triggered by the following code: ``` enum Foo { A = U64_MAX, B } ``` This commit also implements the remaining integer operators for Wrapped<T>.
-
由 Corey Richardson 提交于
Adds overflow checking to integer addition, multiplication, and subtraction when `-Z force-overflow-checks` is true, or if `--cfg ndebug` is not passed to the compiler. On overflow, it panics with `arithmetic operation overflowed`. Also adds `overflowing_add`, `overflowing_sub`, and `overflowing_mul` intrinsics for doing unchecked arithmetic. [breaking-change]
-
由 Felix S. Klock II 提交于
Namely, I have been annoyed in the past when I have done `RUST_BACKTRACE=1 make check` only to discover (again) that such a trick causes this test to fail, because it assumes that the `RUST_BACKTRACE` environment variable is not set.
-
由 Felix S. Klock II 提交于
-
由 Jorge Aparicio 提交于
-
由 Jorge Aparicio 提交于
-
由 Kang Seonghoon 提交于
Also clarified the mysterious `_next_int` method.
-