Impl Default for ranges
Couldn't find an issue about it.
`Range` and friends probably can implement `Default` if `Idx: Default`. For example, the following would be possible:
```rust
#[derive(Default)]
struct Foo(core::ops::RangeToInclusive<u64>);
let _ = [1, 2, 3].get(core::ops::Range::default());
core::ops::RangeFrom::<u8>::default().take(20).for_each(|x| { dbg!(x); });
fn stuff<T: Default>() { let instance = T::default(); ... more stuff }
stuff::<core::ops::RangeTo<f32>>();
```
Maybe there are some concerns about safety or misunderstandings?
Fixes#70718
This commit allows making associated items (e.g. associated functions
and types) into lang items via the `#[lang]` attribute. This allows such
items to be accessed directly, rather than by iterating over the parent
item's associated items.
I've added `FnOnce::Output` as a lang item, and updated one old usage to
use the new lang item. The remaining uses can be updated separately.
If the reader assumes that 'pointer type's include 'smart pointer's,
the term 'non-pointer type' could mislead the reader to assume that
x should not be a smart pointer type. I tried to rephrase the term
'non-pointer type' to remove ambiguity in the doc comments.
closes#72335
Thank you for reviewing this PR! :)
Resolve overflow behavior for RangeFrom
This specifies a documented unspecified implementation detail of `RangeFrom` and makes it consistently implement the specified behavior.
Specifically, `(u8::MAX).next()` is defined to cause an overflow, and resolve that overflow in the same manner as the `Step::forward` implementation.
The inconsistency that has existed is `<RangeFrom as Iterator>::nth`. The existing behavior should be plain to see after #69659: the skipping part previously always panicked if it caused an overflow, but the final step (to set up the state for further iteration) has always been debug-checked.
The inconsistency, then, is that `RangeFrom::nth` does not implement the same behavior as the naive (and default) implementation of just calling `next` multiple times. This PR aligns `RangeFrom::nth` to have identical behavior to the naive implementation. It also lines up with the standard behavior of primitive math in Rust everywhere else in the language: debug checked overflow.
cc @Amanieu
---
Followup to #69659. Closes#25708 (by documenting the panic as intended).
The documentation wording is preliminary and can probably be improved.
This will probably need an FCP, as it changes observable stable behavior.
It's been gone since #23945, before Rust 1.0. The former wrapping
semantics have also been available as inherent methods for a long time
now. There's no reason to keep this unused macro around.
The manual implementation of PartialEq, Eq and Hash for RangeInclusive was functionally equivalent to a derived implementation.
This change removes the manual implementation and adds the respective derives.
A side effect of this change is that the derives also add implementations for StructuralPartialEq and StructuralEq, which enables RangeInclusive to be used in const generics.
Small composite types like `Point { x: i32, y: i32}` are plain
old data and we should encourage users to derive `Copy` on them.
This changes the semantics of the edited examples slightly: instead
of consuming the operands during addition, it will copy them. This
is desired behaviour.
Co-Authored-By: Jake Goulding <shepmaster@mac.com>
Remove some unsound specializations
This removes the unsound and exploitable specializations in the standard library
* The `PartialEq` and `Hash` implementations for `RangeInclusive` are changed to avoid specialization.
* The `PartialOrd` specialization for slices now specializes on a limited set of concrete types.
* Added some tests for the soundness problems.
Require issue = "none" over issue = "0" in unstable attributes
These changes make the use of `issue = "none"` required in unstable attributes throughout the compiler.
Notes:
- #66299 is now in beta so `issue = "none"` is accepted.
- The `tidy` tool now fails on `issue = "0"`.
- Tests that used `issue = "0"` were changed to use `issue = "none"`, except for _one_ that asserts `issue = "0"` can still be used.
- The compiler still allows `issue = "0"` because some submodules require it, this could be disallowed once these are updated.
Resolves#41260
r? @varkor
Add `enclosing scope` parameter to `rustc_on_unimplemented`
Adds a new parameter to `#[rustc_on_unimplemented]`, `enclosing scope`, which highlights the function or closure scope with a message.
The wip part refers to adding this annotation to `Try` trait to improve ergonomics (which I don't know how to do since I change both std and librustc)
Closes#61709.
This commit applies rustfmt with default settings to files in
src/libcore *that are not involved in any currently open PR* to minimize
merge conflicts. The list of files involved in open PRs was determined
by querying GitHub's GraphQL API with this script:
https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8
With the list of files from the script in `outstanding_files`, the
relevant commands were:
$ find src/libcore -name '*.rs' | xargs rustfmt --edition=2018
$ rg libcore outstanding_files | xargs git checkout --
Repeating this process several months apart should get us coverage of
most of the rest of libcore.
When there are multiple implementors for the same trait that is present
in an unmet binding, modify the E0277 error to refer to the parent
obligation and verify whether borrowing the argument being passed in
would satisfy the unmet bound. If it would, suggest it.
Use variant names rather than descriptions for identifying desugarings in `#[rustc_on_unimplemented]`.
Both are highly unstable, but variant name is at least a single identifier.
