| Age | Commit message (Collapse) | Author | Lines |
|---|
|
like map API
|
|
|
|
|
|
- Use if the implementation of [`Ord`] for `T`
language
- Link to total order wiki page
- Rework total order help and examples
- Improve language to be more precise and less
prone to misunderstandings.
- Fix usage of `sort_unstable_by` in `sort_by`
example
- Fix missing author mention
- Use more consistent example input for sort
- Use more idiomatic assert_eq! in examples
- Use more natural "comparison function" language
instead of "comparator function"
|
|
|
|
Bump bootstrap compiler to new beta
https://forge.rust-lang.org/release/process.html#master-bootstrap-update-t-2-day-tuesday
|
|
Optimize empty case in Vec::retain
While profiling some code that happens to call Vec::retain() in a tight loop, I noticed more runtime than expected in retain, even in a bench case where the vector was always empty. When I wrapped my call to retain in `if !myvec.is_empty()` I saw faster execution compared with doing retain on an empty vector.
On closer inspection, Vec::retain is doing set_len(0) on itself even when the vector is empty, and then resetting the length again in BackshiftOnDrop::drop.
Unscientific screengrab of a flamegraph illustrating how we end up spending time in set_len and drop:
|
|
Rollup of 6 pull requests
Successful merges:
- #128182 (handle no_std targets on std builds)
- #128277 (miri: fix offset_from behavior on wildcard pointers)
- #128304 (Isolate the diagnostic code that expects `thir::Pat` to be printable)
- #128307 (Clean and enable `rustdoc::unescaped_backticks` for `core/alloc/std/test/proc_macro`)
- #128322 (CI: move RFL job forward to v6.11-rc1)
- #128333 (Miri subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Clean and enable `rustdoc::unescaped_backticks` for `core/alloc/std/test/proc_macro`
I am not sure if the lint is supposed to be "ready enough" (since it is `allow` by default), but it does catch a couple issues in `core` (`alloc`, `std`, `test` and `proc_macro` are already clean), so I propose making it `warn` in all the crates rendered in the website.
Cc: `@GuillaumeGomez`
|
|
|
|
Update compiler_builtins to 0.1.114
The `weak-intrinsics` feature was removed from compiler_builtins in https://github.com/rust-lang/compiler-builtins/pull/598, so dropped the `compiler-builtins-weak-intrinsics` feature from alloc/std/sysroot.
In https://github.com/rust-lang/compiler-builtins/pull/593, some builtins for f16/f128 were added. These don't work for all compiler backends, so add a `compiler-builtins-no-f16-f128` feature and disable it for cranelift and gcc.
|
|
Add missing periods on `BTreeMap` cursor `peek_next` docs
Tracking issue: https://github.com/rust-lang/rust/issues/107540
|
|
The `weak-intrinsics` feature was removed from compiler_builtins in
https://github.com/rust-lang/compiler-builtins/pull/598, so dropped the
`compiler-builtins-weak-intrinsics` feature from alloc/std/sysroot.
In https://github.com/rust-lang/compiler-builtins/pull/593, some
builtins for f16/f128 were added. These don't work for all compiler
backends, so add a `compiler-builtins-no-f16-f128` feature and disable
it for cranelift and gcc. Also disable it for LLVM targets that don't
support it.
|
|
They are all clean now, so enable the lint to keep them clean going forward.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
|
|
Stabilize `const_waker`
Closes: https://github.com/rust-lang/rust/issues/102012.
For `local_waker` and `context_ext` related things, I just ~~moved them to dedicated feature gates and reused their own tracking issue (maybe it's better to open a new one later, but at least they should not be tracked under https://github.com/rust-lang/rust/issues/102012 from the beginning IMO.)~~ reused their own feature gates as suggested by ``@tgross35.``
``@rustbot`` label: +T-libs-api
r? libs-api
|
|
Fix doc nits
Many tiny changes to stdlib doc comments to make them consistent (for example "Returns foo", rather than "Return foo"), adding missing periods, paragraph breaks, backticks for monospace style, and other minor nits.
|
|
|
|
|
|
|
|
Stabilize `is_sorted`
Closes: https://github.com/rust-lang/rust/issues/53485.
~~Question: does~~ https://github.com/rust-lang/rust/blob/8fe0c753f23e7050b87a444b6622caf4d2272d5d/compiler/rustc_lint_defs/src/builtin.rs#L1986-L1994 ~~need a new example?~~
edit: It causes a test failure and needs to be changed anyway.
``@rustbot`` label: +T-libs-api
r? libs-api
|
|
|
|
from_ref, from_mut: clarify documentation
This was brought up [here](https://github.com/rust-lang/rust/issues/56604#issuecomment-2143193486). The domain of quantification is generally always constrained by the type in the type signature, and I am not sure it's always worth spelling that out explicitly as that makes things exceedingly verbose. But since this was explicitly brought up, let's clarify.
|
|
- Move panic information into # Panics section
- Fix mentions of T: Ord that should be compare
- Add missing information
|
|
|
|
|
|
Many tiny changes to stdlib doc comments to make them consistent (for example
"Returns foo", rather than "Return foo", per RFC1574), adding missing periods, paragraph
breaks, backticks for monospace style, and other minor nits.
https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md#appendix-a-full-conventions-text
|
|
Gate `AsyncFn*` under `async_closure` feature
T-lang has not come to a consensus on the naming of async closure callable bounds, and as part of allowing the async closures RFC merge, we agreed to place `AsyncFn` under the same gate as `async Fn` so that these syntaxes can be evaluated in parallel.
See https://github.com/rust-lang/rfcs/pull/3668#issuecomment-2246435537
r? oli-obk
|
|
Replace some `mem::forget`'s with `ManuallyDrop`
> but I would like to see a larger effort to replace all uses of `mem::forget`.
_Originally posted by `@saethlin` in https://github.com/rust-lang/rust/issues/127584#issuecomment-2226087767_
So,
r? `@saethlin`
Sorry, I have finished writing all of this before I got your response.
|
|
Remove generic lifetime parameter of trait `Pattern`
Use a GAT for `Searcher` associated type because this trait is always implemented for every lifetime anyway.
cc #27721
|
|
Update tracking issue for `const_binary_heap_new_in`
This PR updates the tracking issue of `const_binary_heap_new_in` feature:
- Old issue: #112353
- New issue: #125961
|
|
|
|
Add missing try_new_uninit_slice_in and try_new_zeroed_slice_in
The methods for fallible slice allocation in a given allocator were missing from `Box`, which was an oversight according to https://github.com/rust-lang/wg-allocators/issues/130
This PR adds them as `try_new_uninit_slice_in` and `try_new_zeroed_slice_in`. I simply copy-pasted the implementations of `try_new_uninit_slice` and `try_new_zeroed_slice` and adusted doc comment, typings, and the allocator it uses internally.
Also adds missing punctuation to the doc comments of `try_new_uninit_slice` and `try_new_zeroed_slice`.
Related issue is https://github.com/rust-lang/rust/issues/32838 (Allocator traits and std::heap) *I think*. Also relevant is https://github.com/rust-lang/rust/issues/63291, but I did not add the corresponding `#[unstable]` proc macro, since `try_new_uninit_slice` and `try_new_zeroed_slice` are also not annotated with it.
|
|
|
|
When we do the big `use` reformatting there are a tiny number of cases
where rustfmt moves a comment from one `use` item to another in an
undesirable way. This commit pre-emptively rearranges things to prevent
this from happening.
|
|
|
|
Use a GAT for `Searcher` associated type because this trait is always
implemented for every lifetime anyway.
|
|
r=Mark-Simulacrum
Remove memory leaks in doctests in `core`, `alloc`, and `std`
cc `@RalfJung` https://github.com/rust-lang/rust/issues/126067 https://github.com/rust-lang/miri/issues/3670
Should be no actual *documentation* changes[^1], all added/modified lines in the doctests are hidden with `#`,
This PR splits the existing memory leaks in doctests in `core`, `alloc`, and `std` into two general categories:
1. "Non-focused" memory leaks that are incidental to the thing being documented, and/or are easy to remove, i.e. they are only there because preventing the leak would make the doctest less clear and/or concise.
- These doctests simply have a comment like `# // Prevent leaks for Miri.` above the added line that removes the memory leak.
- [^2]Some of these would perhaps be better as part of the public documentation part of the doctest, to clarify that a memory leak can happen if it is not otherwise mentioned explicitly in the documentation (specifically the ones in `(A)Rc::increment_strong_count(_in)`).
2. "Focused" memory leaks that are intentional and documented, and/or are possibly fragile to remove.
- These doctests have a `# // FIXME` comment above the line that removes the memory leak, with a note that once `-Zmiri-disable-leak-check` can be applied at test granularity, these tests should be "un-unleakified" and have `-Zmiri-disable-leak-check` enabled.
- Some of these are possibly fragile (e.g. unleaking the result of `Vec::leak`) and thus should definitely not be made part of the documentation.
This should be all of the leaks currently in `core` and `alloc`. I only found one leak in `std`, and it was in the first category (excluding the modules `@RalfJung` mentioned in https://github.com/rust-lang/rust/issues/126067 , and reducing the number of iterations of [one test](https://github.com/rust-lang/rust/blob/master/library/std/src/sync/once_lock.rs#L49-L94) from 1000 to 10)
[^1]: assuming [^2] is not added
[^2]: backlink
|
|
Generalize `fn allocator` for Rc/Arc.
Split out from #119761
- For `Rc`/`Arc`, the existing associated `fn`s are changed to allow unsized pointees.
- For `Weak`s, new methods are added.
`````@rustbot````` label +A-allocators
|
|
|
|
r=pietroalbini
do not run test where it cannot run
This was seen on Ferrocene, where we have a custom test target that does not have unwind support
|
|
This was seen on Ferrocene, where we have a custom test target that does not have unwind support
|
|
Mark format! with must_use hint
Uses unstable feature https://github.com/rust-lang/rust/issues/94745
Part of #126475
First contribution to rust, please let me know if the blessing of tests is correct
Thanks `@bjorn3` for the help
|
|
r=compiler-errors,oli-obk,lnicola
Make casts of pointers to trait objects stricter
This is an attempt to `fix` https://github.com/rust-lang/rust/issues/120222 and https://github.com/rust-lang/rust/issues/120217.
This is done by adding restrictions on casting pointers to trait objects.
Before this PR the rules were as follows:
> When casting `*const X<dyn A>` -> `*const Y<dyn B>`, principal traits in `A` and `B` must refer to the same trait definition (or no trait).
With this PR the rules are changed to
> When casting `*const X<dyn Src>` -> `*const Y<dyn Dst>`
> - if `Dst` has a principal trait `DstP`,
> - `Src` must have a principal trait `SrcP`
> - `dyn SrcP` and `dyn DstP` must be the same type (modulo the trait object lifetime, `dyn T+'a` -> `dyn T+'b` is allowed)
> - Auto traits in `Dst` must be a subset of auto traits in `Src`
> - Not adhering to this is currently a FCW (warn-by-default + `FutureReleaseErrorReportInDeps`), instead of an error
> - if `Src` has a principal trait `Dst` must as well
> - this restriction will be removed in a follow up PR
This ensures that
1. Principal trait's generic arguments match (no `*const dyn Tr<A>` -> `*const dyn Tr<B>` casts, which are a problem for [#120222](https://github.com/rust-lang/rust/issues/120222))
2. Principal trait's lifetime arguments match (no `*const dyn Tr<'a>` -> `*const dyn Tr<'b>` casts, which are a problem for [#120217](https://github.com/rust-lang/rust/issues/120217))
3. No auto traits can be _added_ (this is a problem for arbitrary self types, see [this comment](https://github.com/rust-lang/rust/pull/120248#discussion_r1463835350))
Some notes:
- We only care about the metadata/last field, so you can still cast `*const dyn T` to `*const WithHeader<dyn T>`, etc
- The lifetime of the trait object itself (`dyn A + 'lt`) is not checked, so you can still cast `*mut FnOnce() + '_` to `*mut FnOnce() + 'static`, etc
- This feels fishy, but I couldn't come up with a reason it must be checked
The diagnostics are currently not great, to say the least, but as far as I can tell this correctly fixes the issues.
cc `@oli-obk` `@compiler-errors` `@lcnr`
|
|
Run alloc sync tests
I was browsing the code and this struck me as weird. We're not running some doc tests because, the comment says, Windows builders deadlock. That should absolutely not happen, at least with our current implementation. And if it does happen I'd like to know.
Just to be sure though I'll do some try builds.
try-job: x86_64-msvc
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-mingw
|
|
Rollup of 8 pull requests
Successful merges:
- #127179 (Print `TypeId` as hex for debugging)
- #127189 (LinkedList's Cursor: method to get a ref to the cursor's list)
- #127236 (doc: update config file path in platform-support/wasm32-wasip1-threads.md)
- #127297 (Improve std::Path's Hash quality by avoiding prefix collisions)
- #127308 (Attribute cleanups)
- #127354 (Describe Sized requirements for mem::offset_of)
- #127409 (Emit a wrap expr span_bug only if context is not tainted)
- #127447 (once_lock: make test not take as long in Miri)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
LinkedList's Cursor: method to get a ref to the cursor's list
We're already providing `.back()` & `.front()`, for which we hold onto a reference to the parent list, so why not share it? Useful for when you got `LinkedList` -> `CursorMut` -> `Cursor` and cannot take another ref to the list, even though you should be able to. This seems to be completely safe & sound.
The name is, of course, bikesheddable.
|
|
Don't check the capacity every time (and also for `Extend` for tuples, as this is how `unzip()` is implemented).
I did this with an unsafe method on `Extend` that doesn't check for growth (`extend_one_unchecked()`). I've marked it as perma-unstable currently, although we may want to expose it in the future so collections outside of std can benefit from it. Then specialize `Extend for (A, B)` for `TrustedLen` to call it.
It may seem that an alternative way of implementing this is to have a semi-public trait (`#[doc(hidden)]` public, so collections outside of core can implement it) for `extend()` inside tuples, and specialize it from collections. However, it is impossible due to limitations of `min_specialization`.
A concern that may arise with the current approach is that implementing `extend_one_unchecked()` correctly must also incur implementing `extend_reserve()`, otherwise you can have UB. This is a somewhat non-local safety invariant. However, I believe this is fine, since to have actual UB you must have unsafe code inside your `extend_one_unchecked()` that makes incorrect assumption, *and* not implement `extend_reserve()`. I've also documented this requirement.
|
|
If/when `-Zmiri-disable-leak-check` is able to be used at test-granularity, it should applied to these tests instead of unleaking.
|
