Give built-in macros stable addresses in the standard library
Continuation of https://github.com/rust-lang/rust/pull/62086.
Derive macros corresponding to traits from libcore are now available through the same paths as those traits:
- `Clone` - `{core,std}::clone::Clone`
- `PartialEq` - `{core,std}::cmp::PartialEq`
- `Eq` - `{core,std}::cmp::Eq`
- `PartialOrd` - `{core,std}::cmp::PartialOrd`
- `Ord` - `{core,std}::cmp::Ord`
- `Default` - `{core,std}::default::Default`
- `Debug` - `{core,std}::fmt::Debug`
- `Hash` - `{core,std}:#️⃣:Hash`
- `Copy` - `{core,std}::marker::Copy`
Fn-like built-in macros are now available through libcore and libstd's root module, by analogy with non-builtin macros defined by libcore and libstd:
```rust
{core,std}::{
__rust_unstable_column,
asm,
assert,
cfg,
column,
compile_error,
concat,
concat_idents,
env,
file,
format_args,
format_args_nl,
global_asm,
include,
include_bytes,
include_str,
line,
log_syntax,
module_path,
option_env,
stringify,
trace_macros,
}
```
Derive macros without a corresponding trait in libcore or libstd are still available only through prelude (also see https://github.com/rust-lang/rust/pull/62507).
Attribute macros also keep being available only through prelude, mostly because they don't have an existing practice to follow. An advice from the library team on their eventual placement would be appreciated.
```rust
RustcDecodable,
RustcEncodable,
bench,
global_allocator,
test,
test_case,
```
r? @alexcrichton
enable flt2dec tests in Miri
With ldexp implemented (thanks to @christianpoveda), we can finally enable these tests in Miri. Well, most of them -- some are just too slow.
Remove gensym in format_args
This also fixes some things to allow us to export opaque macros from libcore:
* Don't consider items that are only reachable through opaque macros as public/exported (so they aren't linted as needing docs)
* Mark private items reachable from the root of libcore as unstable - they are now reachable (in principle) in other crates via macros in libcore
r? @petrochenkov
Improve `ptr_rotate` performance, tests, and benches
The corresponding issue is #61784. I am not actually sure if miri can handle the test, but I can change the commit if necessary.
move of packed fields might or might not occur when they actually are sufficiently aligned
See https://github.com/taiki-e/pin-project/pull/34, where it was pointed out that we actually don't move fields of 1-aligned types when dropping a packed struct -- but e.g. in a `packed(2)` struct, we don't do something similar for 2-aligned types. The code for that is [here](db7c773a6b/src/librustc_mir/util/alignment.rs (L7)).
bump rand in libcore/liballoc test suites
This pulls in the fix for https://github.com/rust-random/rand/issues/779, which trips Miri when running these test suites.
`SmallRng` (formerly used by libcore) is no longer built by default, it needs a feature gate. I opted to switch to `StdRng` instead. Or should I enable the feature gate?
Fix generator size regressions due to optimization
I tested the generator optimizations in #60187 and #61922 on the Fuchsia
build, and noticed that some small generators (about 8% of the async fns
in our build) increased in size slightly.
This is because in #60187 we split the fields into two groups, a
"prefix" non-overlap region and an overlap region, and lay them out
separately. This can introduce unnecessary padding bytes between the two
groups.
In every single case in the Fuchsia build, it was due to there being
only a single variant being used in the overlap region. This means that
we aren't doing any overlapping, period. So it's better to combine the
two regions into one and lay out all the fields at once, which is what
this change does.
r? @cramertj
cc @eddyb @Zoxc
Use internal iteration in the Sum and Product impls of Result and Option
This PR adds internal iteration to the `ResultShunt` iterator type underlying the `Sum` and `Product` impls of `Result`. I had to change `ResultShunt` to hold a mutable reference to an error instead, similar to `itertools::ProcessResults`, in order to be able to pass the `ResultShunt` itself by value (which is necessary for internal iteration).
`ResultShunt::process` can unfortunately no longer be an associated function because that would make it generic over the lifetime of the error reference, which wouldn't work, so I turned it into the free function `process_results`.
I removed the `OptionShunt` type and forwarded the `Sum` and `Product` impls of `Option` to their respective impls of `Result` instead, to avoid having to repeat the internal iteration logic.
fix UB in a test
We used to compare two mutable references that were supposed to point to the same thing. That's no good.
Compare them as raw pointers instead.
Implement DoubleEndedIterator for iter::{StepBy, Peekable, Take}
Now that `DoubleEndedIterator::nth_back` has landed, `StepBy` and `Take` can have an efficient `DoubleEndedIterator` implementation. I don't know if there was any particular reason for `Peekable` not having a `DoubleEndedIterator` implementation, but it's quite trivial and I don't see any drawbacks to having it.
I'm not very happy about the implementation of `Peekable::try_rfold`, but I didn't see another way to only take the value out of `self.peeked` in case `self.iter.try_rfold` didn't exit early.
I only added `Peekable::rfold` (in addition to `try_rfold`) because its `Iterator` implementation has both `fold` and `try_fold` (and for similar reasons I added `Take::try_rfold` but not `Take::rfold`). Do we have any guidelines on whether we want both? If we do want both, maybe we should investigate which iterator adaptors override `try_fold` but not `fold` and add the missing implementations. At the moment I think that it's better to always have iterator adaptors implement both, because some iterators have a simpler `fold` implementation than their `try_fold` implementation.
The tests that I added may not be sufficient because they're all just existing tests where `next`/`nth`/`fold`/`try_fold` are replaced by their DEI counterparts, but I do think all paths are covered. Is there anything in particular that I should probably also test?
