| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Make <*const/mut T>::offset_from `const fn`
This reenables offset_of cc @mjbshaw after https://github.com/rust-lang/rust/pull/63075 broke it
|
|
Stabilize float_to_from_bytes feature
FCP completed in https://github.com/rust-lang/rust/issues/60446#issuecomment-548440175
Closes #60446
|
|
doc: reword iter module example and mention other methods
|
|
Make ItemContext available for better diagnositcs
Fix #62570
|
|
|
|
|
|
|
|
|
|
|
|
doc: introduce `once` in `iter::chain` document
I find it hard to find which one to use with `chain` when I only need to
chain one value. Also [`once`][1] talks about `chain`.
[1]: https://doc.rust-lang.org/nightly/std/iter/fn.once.html
|
|
`std::panic::Location` is a lang_item, add `core::intrinsics::caller_location` (RFC 2091 3/N)
[Tracking issue](https://github.com/rust-lang/rust/issues/47809)
[RFC text](https://github.com/rust-lang/rfcs/blob/master/text/2091-inline-semantic.md)
@eddyb suggested doing this intrinsic implementation ahead of actually implementing the `#[track_caller]` attribute so that there's an easily tested intermediate step between adding the shim and wiring up the attribute.
|
|
Stabilize `Option::flatten`
- PR: https://github.com/rust-lang/rust/pull/60256
- Tracking issue: https://github.com/rust-lang/rust/issues/60258
@elahn
> I was trying to `flat_map()` and found `map().flatten()` does the trick. This has been on nightly for 4 months, can we stabilise it?
@ethanboxx
> @Centril Helped me get this merged. What is the stabilization process?
@Centril
> @ethanboxx I'd just file a PR to stabilize it and we'll ask T-libs to FCP.
So here I am.
I am was unsure what number to put in `since = "-"` so I copied what someone had done in a recent PR.
|
|
|
|
This allows us to remove `static_panic_msg` from the SSA<->LLVM
boundary, along with its fat pointer representation for &str.
Also changes the signature of PanicInfo::internal_contructor to
avoid copying.
Closes #65856.
|
|
Returns a `&core::panic::Location` corresponding to where it was
called, also making `Location` a lang item.
|
|
r=matthewjasper
trait-based structural match implementation
Moves from using a `#[structural_match]` attribute to using a marker trait (or pair of such traits, really) instead.
Fix #63438.
(This however does not remove the hacks that I believe were put into place to support the previous approach of injecting the attribute based on the presence of both derives... I have left that for follow-on work.)
|
|
Add [T]::as_ptr_range() and [T]::as_mut_ptr_range().
Implementation of https://github.com/rust-lang/rfcs/pull/2791
|
|
LukasKalbertodt:fill-array-value-iter-tracking-issue, r=Centril
Fill tracking issue number for `array_value_iter`
Thanks for [noticing](https://github.com/rust-lang/rust/pull/62959#discussion_r338930448)!
r? @Centril
|
|
|
|
|
|
|
|
(Or more precisely, a pair of such traits: one for `derive(PartialEq)` and one
for `derive(Eq)`.)
((The addition of the second marker trait, `StructuralEq`, is largely a hack to
work-around `fn (&T)` not implementing `PartialEq` and `Eq`; see also issue
rust-lang/rust#46989; otherwise I would just check if `Eq` is implemented.))
Note: this does not use trait fulfillment error-reporting machinery; it just
uses the trait system to determine if the ADT was tagged or not. (Nonetheless, I
have kept an `on_unimplemented` message on the new trait for structural_match
check, even though it is currently not used.)
Note also: this does *not* resolve the ICE from rust-lang/rust#65466, as noted
in a comment added in this commit. Further work is necessary to resolve that and
other problems with the structural match checking, especially to do so without
breaking stable code (adapted from test fn-ptr-is-structurally-matchable.rs):
```rust
fn r_sm_to(_: &SM) {}
fn main() {
const CFN6: Wrap<fn(&SM)> = Wrap(r_sm_to);
let input: Wrap<fn(&SM)> = Wrap(r_sm_to);
match Wrap(input) {
Wrap(CFN6) => {}
Wrap(_) => {}
};
}
```
where we would hit a problem with the strategy of unconditionally checking for
`PartialEq` because the type `for <'a> fn(&'a SM)` does not currently even
*implement* `PartialEq`.
----
added review feedback:
* use an or-pattern
* eschew `return` when tail position will do.
* don't need fresh_expansion; just add `structural_match` to appropriate `allow_internal_unstable` attributes.
also fixed example in doc comment so that it actually compiles.
|
|
|
|
See https://github.com/rust-lang/rfcs/pull/2791 for motivation.
|
|
|
|
This commit stabilizes RFC 2008 (#44109) by removing the feature gate.
Signed-off-by: David Wood <david@davidtw.co>
|
|
Many tests are based on tests by Josh Stone <cuviper@gmail.com>
|
|
The iterator is implemented using const generics. It implements the
traits `Iterator`, `DoubleEndedIterator`, `ExactSizeIterator`,
`FusedIterator` and `TrustedLen`. It also contains a public method
`new` to create it from an array.
`IntoIterator` was not implemented for arrays yet, as there are still
some open questions regarding backwards compatibility. This commit
only adds the iterator impl and does not yet offer a convenient way
to obtain that iterator.
|
|
Add the `matches!( $expr, $pat ) -> bool` macro
# Motivation
This macro is:
* General-purpose (not domain-specific)
* Simple (the implementation is short)
* Very popular [on crates.io](https://crates.io/crates/matches) (currently 37th in all-time downloads)
* The two previous points combined make it number one in [left-pad index](https://twitter.com/bascule/status/1184523027888988160) score
As such, I feel it is a good candidate for inclusion in the standard library.
In fact I already felt that way five years ago: https://github.com/rust-lang/rust/pull/14685 (Although the proof of popularity was not as strong at the time.)
# API
<details>
<del>
Back then, the main concern was that this macro may not be quite universally-enough useful to belong in the prelude.
Therefore, this PR adds the macro such that using it requires one of:
```rust
use core::macros::matches;
use std::macros::matches;
```
</del>
</details>
Like arms of a `match` expression, the macro supports multiple patterns separated by `|` and optionally followed by `if` and a guard expression:
```rust
let foo = 'f';
assert!(matches!(foo, 'A'..='Z' | 'a'..='z'));
let bar = Some(4);
assert!(matches!(bar, Some(x) if x > 2));
```
<details>
<del>
# Implementation constraints
A combination of reasons make it tricky for a standard library macro not to be in the prelude.
Currently, all public `macro_rules` macros in the standard library macros end up “in the prelude” of every crate not through `use std::prelude::v1::*;` like for other kinds of items, but through `#[macro_use]` on `extern crate std;`. (Both are injected by `src/libsyntax_ext/standard_library_imports.rs`.)
`#[macro_use]` seems to import every macro that is available at the top-level of a crate, even if through a `pub use` re-export.
Therefore, for `matches!` not to be in the prelude, we need it to be inside of a module rather than at the root of `core` or `std`.
However, the only way to make a `macro_rules` macro public outside of the crate where it is defined appears to be `#[macro_export]`. This exports the macro at the root of the crate regardless of which module defines it. See [macro scoping](https://doc.rust-lang.org/reference/macros-by-example.html#scoping-exporting-and-importing) in the reference.
Therefore, the macro needs to be defined in a crate that is not `core` or `std`.
# Implementation
This PR adds a new `matches_macro` crate as a private implementation detail of the standard library. This crate is `#![no_core]` so that libcore can depend on it. It contains a `macro_rules` definition with `#[macro_export]`.
libcore and libstd each have a new public `macros` module that contains a `pub use` re-export of the macro. Both the module and the macro are unstable, for now.
The existing private `macros` modules are renamed `prelude_macros`, though their respective source remains in `macros.rs` files.
</del>
</details>
|
|
|
|
https://github.com/rust-lang/rust/issues/65721
|
|
|
|
# Motivation
This macro is:
* General-purpose (not domain-specific)
* Simple (the implementation is short)
* Very popular [on crates.io](https://crates.io/crates/matches)
(currently 37th in all-time downloads)
* The two previous points combined make it number one in
[left-pad index](https://twitter.com/bascule/status/1184523027888988160)
score
As such, I feel it is a good candidate for inclusion in the standard library.
In fact I already felt that way five years ago:
https://github.com/rust-lang/rust/pull/14685
(Although the proof of popularity was not as strong at the time.)
Back then, the main concern was that this macro may not be quite
universally-enough useful to belong in the prelude.
# API
Therefore, this PR adds the macro such that using it requires one of:
```
use core::macros::matches;
use std::macros::matches;
```
Like arms of a `match` expression,
the macro supports multiple patterns separated by `|`
and optionally followed by `if` and a guard expression:
```
let foo = 'f';
assert!(matches!(foo, 'A'..='Z' | 'a'..='z'));
let bar = Some(4);
assert!(matches!(bar, Some(x) if x > 2));
```
# Implementation constraints
A combination of reasons make it tricky
for a standard library macro not to be in the prelude.
Currently, all public `macro_rules` macros in the standard library macros
end up “in the prelude” of every crate not through `use std::prelude::v1::*;`
like for other kinds of items,
but through `#[macro_use]` on `extern crate std;`.
(Both are injected by `src/libsyntax_ext/standard_library_imports.rs`.)
`#[macro_use]` seems to import every macro that is available
at the top-level of a crate, even if through a `pub use` re-export.
Therefore, for `matches!` not to be in the prelude, we need it to be
inside of a module rather than at the root of `core` or `std`.
However, the only way to make a `macro_rules` macro public
outside of the crate where it is defined
appears to be `#[macro_export]`.
This exports the macro at the root of the crate
regardless of which module defines it.
See [macro scoping](
https://doc.rust-lang.org/reference/macros-by-example.html#scoping-exporting-and-importing)
in the reference.
Therefore, the macro needs to be defined in a crate
that is not `core` or `std`.
# Implementation
This PR adds a new `matches_macro` crate as a private implementation detail
of the standard library.
This crate is `#![no_core]` so that libcore can depend on it.
It contains a `macro_rules` definition with `#[macro_export]`.
libcore and libstd each have a new public `macros` module
that contains a `pub use` re-export of the macro.
Both the module and the macro are unstable, for now.
The existing private `macros` modules are renamed `prelude_macros`,
though their respective source remains in `macros.rs` files.
|
|
|
|
|
|
|
|
make is_power_of_two a const function
This makes `is_power_of_two` a const function by using `&` instead of short-circuiting `&&`; Rust supports bitwise `&` for `bool` and short-circuiting is not required in the existing expression.
I don't think this needs a const-hack label as I don't find the changed code less readable, if anything I prefer that it is clearer that short circuiting is not used.
@oli-obk
|
|
|
|
Rename the default argument 'def' to 'default'
Fixes: #65492
|
|
Remove leading :: from paths in doc examples
Noted some pre-2018 path syntax in the doc examples, for example:
https://doc.rust-lang.org/std/process/fn.exit.html
```rust
fn main() {
::std::process::exit(match run_app() {
Ok(_) => 0,
...
```
Couldn't find an existing issue on this (then again, "::" makes for an annoying thing to search for) so if there is already something fixing this and/or there's a reason to not fix it, just close this PR.
(Also fixed indentation in the `process::exit()` docs)
|
|
Fixes: #65492
|
|
|
|
Remove unneeded `ref` from docs
Will reduce confusion like in https://users.rust-lang.org/t/help-understanding-the-ref-t-syntax/33779 since match ergonomics means you (almost) never have to say `ref` anymore!
There might be more like this, but I don't have a checkout on my computer right this second and I'm on slow wifi and GitHub search isn't powerful enough and that's my story.
|
|
Inline `ptr::null(_mut)` even in debug builds
I think we should treat `ptr::null(_mut)` as a constant. As It may help reduce code size
in debug build.
See godbolt link: https://godbolt.org/z/b9YMtD
|
|
Will reduce confusion like in https://users.rust-lang.org/t/help-understanding-the-ref-t-syntax/33779 since match ergonomics means you (almost) never have to say `ref` anymore!
|
|
|
|
Fix left/right shift typo in wrapping rotate docs
This makes the note similar to the one found on rotate functions for primitive types like i32/u32.
|
|
properly document panics in div_euclid and rem_euclid
For signed numbers, document that `div_euclid` and `rem_euclid` panic not just when `rhs` is 0, but also when the division overflows.
For unsigned numbers, document that `div_euclid` and `rem_euclid` panic when `rhs` is 0.
|
|
Always inline `mem::{size_of,align_of}` in debug builds
Those two are const fn and do not have any arguments. Inlining
helps reducing generated code size in debug builds.
See also #64996.
|
|
This makes the note similar to the one found on rotate functions for
primitive types like i32/u32.
|
