Runway for RFC 809 (overloaded box/placement-in) by adding type annotations or explicit calls to `Box::new` where I found it necessary on PR #22086.
I have broken this up into more than one PR because the entire commit chain (see PR #22086) is long, widespread and unwieldy to rebase frequently.
To my knowledge this is not a breaking change. Also, there is in principle nothing stopping someone from reverting some/all of these annotations, since without the rest of the commit chain in #22086, the associated code would continue to compile.
All I can do is ask: Try to discourage others from removing seemingly "unnecessary" uses of the `Box` type or the `Box::new()` function, until the rest of RFC 809 lands.
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.
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.
Make build timestamp files robust in face of concurrent source modification.
Strategy: If the end goal is to touch e.g. `stamp.std`, then we first touch `stamp.std.start_time` before doing anything else. Then when the receipe finishes, we touch `stamp.std` using the timestamp from `stamp.std.start_time` as the reference time, and remove `stamp.std.start_time`.
Fix#6518.
Rebase and follow-through on work done by @cmr and @aatch.
Implements most of rust-lang/rfcs#560. Errors encountered from the checks during building were fixed.
The checks for division, remainder and bit-shifting have not been implemented yet.
See also PR #20795
cc @Aatch ; cc @nikomatsakis
Strategy: If the end goal is to touch e.g. `stamp.std`, then we first
touch `stamp.std.start_time` before doing anything else. Then when
the receipe finishes, we touch `stamp.std` using the timestamp from
`stamp.std.start_time` as the reference time, and remove
`stamp.std.start_time`.
Fix#6518.
Make `test/run-pass/backtrace.rs` more robust about own host environment
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.
Fix#22870
aarch64-linux-android build has been broken since #22839.
Aarch64 android has _Unwind_GetIPInfo, so re-define this only for arm32 android.
r? @alexcrichton
This changes the type of some public constants/statics in libunicode.
Notably some `&'static &'static [(char, char)]` have changed
to `&'static [(char, char)]`. The regexp crate seems to be the
sole user of these, yet this is technically a [breaking-change]
Associated types are now treated as part of the public API by the privacy checker.
If you were exposing a private type in your public API via an associated type, make that type public:
``` diff
pub struct PublicType { .. }
- struct Struct { .. }
+ pub struct Struct { .. }
pub trait PublicTrait {
type Output;
fn foo(&self) -> Self::Output;
}
impl PublicTrait for PublicType {
type Output = Struct;
fn foo(&self) -> Struct { // `Struct` is part of the public API, it must be marked as `pub`lic
..
}
}
```
[breaking-change]
---
r? @nikomatsakis
closes#22912
Fix the return type in the comments.
An old commit 082bfde412 (\"Fallout of std::str stabilization\") removed
the example of FromStr::from_str(), this commit adds it back. But
the example of StrExt::parse() is still kept with an additinal note.
Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
The API this exposes is a little strange (being attached to `static`s),
so it makes sense to conservatively feature gate it. If it is highly
popular, it is possible to reverse this gating.
* The lint visitor's visit_ty method did not recurse, and had a
reference to the now closed#10894
* The newly enabled recursion has only affected the `deprectated` lint
which now detects uses of deprecated items in trait impls and
function return types
* Renamed some references to `CowString` and `CowVec` to `Cow<str>` and
`Cow<[T]>`, respectively, which appear outside of the crate which
defines them
* Replaced a few instances of `InvariantType<T>` with
`PhantomData<Cell<T>>`
* Disabled the `deprecated` lint in several places that
reference/implement traits on deprecated items which will get cleaned
up in the future
* Unfortunately, this means that if a library declares
`#![deny(deprecated)]` and marks anything as deprecated, it will have
to disable the lint for any uses of said item, e.g. any impl the now
deprecated item
For any library that denies deprecated items but has deprecated items
of its own, this is a [breaking-change]
I had originally intended for the lint to ignore uses of deprecated items that are declared in the same crate, but this goes against some previous test cases that expect the lint to capture *all* uses of deprecated items, so I maintained the previous approach to avoid changing the expected behavior of the lint.
Tested locally on OS X, so hopefully there aren't any deprecated item uses behind a `cfg` that I may have missed.
* Make num::UpperHex private. I was unable to determine why this struct
is public. The num module itself is not public, and the UpperHex struct
is not referenced anywhere in the core::fmt module. (Only the UpperHex
trait is reference.) num::LowerHex is not public.
* Remove the suffix parameters from the macros that generate integral
display traits.
The code to print the Debug::fmt suffixes was removed when Show was
renamed to Debug. It was an intentional change. From RFC 0565:
* Focus on the *runtime* aspects of a type; repeating information such
as suffixes for integer literals is not generally useful since that
data is readily available from the type definition.
* Because Show was renamed to Debug, rename show! to debug!.
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.)
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.
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.)
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.
(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.)
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.
* `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`.
* 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.
* `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:#️⃣:table` : Use `OverflowingOps` trait to
track overflow during `calculate_offsets` and `calculate_allocation`
functions.
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.
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.
