rust - https://github.com/rust-lang/rust

Age	Commit message (Collapse)	Author	Lines
2022-06-10	additional docs example for replace all of str	bvanjoi	-0/+1

2022-05-26	improve case conversion happy path	Conrad Ludgate	-5/+69

2022-04-05	trivial cfg(bootstrap) changes	Pietro Albini	-10/+9

2022-03-30	remove now unnecessary lang items	lcnr	-1/+1

2022-03-30	rework implementation for inherent impls for builtin types	lcnr	-0/+9

2021-12-08	Use spare_capacity_mut instead of invalid unchecked indexing	Ben Kimock	-2/+10

2021-11-05	Fix `str::SplitInclusive` stabilisation date	mbartlett21	-1/+1

2021-10-15	Add #[must_use] to remaining alloc functions	John Kugelman	-1/+4

2021-10-12	Fix uppercase/lowercase error	John Kugelman	-1/+1

2021-10-10	Add #[must_use] to from_value conversions	John Kugelman	-0/+1

2021-10-09	Add #[must_use] to string/char transformation methods	John Kugelman	-0/+6
	These methods could be misconstrued as modifying their arguments instead of returning new values. Where possible I made the note recommend a method that does mutate in place.
2021-06-23	Use HTTPS links where possible	Smitty	-1/+1

2021-05-05	alloc: Add unstable Cfg feature `no-global_oom_handling`	John Ericson	-0/+13
	For certain sorts of systems, programming, it's deemed essential that all allocation failures be explicitly handled where they occur. For example, see Linus Torvald's opinion in [1]. Merely not calling global panic handlers, or always `try_reserving` first (for vectors), is not deemed good enough, because the mere presence of the global OOM handlers is burdens static analysis. One option for these projects to use rust would just be to skip `alloc`, rolling their own allocation abstractions. But this would, in my opinion be a real shame. `alloc` has a few `try_` methods already, and we could easily have more. Features like custom allocator support also demonstrate and existing to support diverse use-cases with the same abstractions. A natural way to add such a feature flag would a Cargo feature, but there are currently uncertainties around how std library crate's Cargo features may or not be stable, so to avoid any risk of stabilizing by mistake we are going with a more low-level "raw cfg" token, which cannot be interacted with via Cargo alone. Note also that since there is no notion of "default cfg tokens" outside of Cargo features, we have to invert the condition from `global_oom_handling` to to `not(no_global_oom_handling)`. This breaks the monotonicity that would be important for a Cargo feature (i.e. turning on more features should never break compatibility), but it doesn't matter for raw cfg tokens which are not intended to be "constraint solved" by Cargo or anything else. To support this use-case we create a new feature, "global-oom-handling", on by default, and put the global OOM handler infra and everything else it that depends on it behind it. By default, nothing is changed, but users concerned about global handling can make sure it is disabled, and be confident that all OOM handling is local and explicit. For this first iteration, non-flat collections are outright disabled. `Vec` and `String` don't yet have `try_` allocation methods, but are kept anyways since they can be oom-safely created "from parts", and we hope to add those `try_` methods in the future. [1]: https://lore.kernel.org/lkml/CAHk-=wh_sNLoz84AUUzuqXEsYH35u=8HV3vK-jbRbJ_B-JjGrg@mail.gmail.com/
2021-03-28	Auto merge of #81728 - Qwaz:fix-80335, r=joshtriplett	bors	-19/+25
	Fixes API soundness issue in join() Fixes #80335
2021-03-23	Bump alloc::str::SplitInclusive to 1.53.0 release	David Tolnay	-1/+1

2021-03-23	Expose str::SplitInclusive in alloc and therefore in std	Ian Jackson	-0/+2
	This seems to have been omitted from the beginning when this feature was first introduced in 86bf96291d82. Most users won't need to name this type which is probably why this wasn't noticed in the meantime. Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
2021-03-20	Update the comment	Yechan Bae	-4/+4

2021-02-25	Convert primitives to use intra-doc links	Joshua Nelson	-1/+1

2021-02-03	Fixes #80335	Yechan Bae	-18/+24

2020-12-31	Remove many unnecessary manual link resolves from library	Camelid	-2/+0
	Now that #76934 has merged, we can remove a lot of these! E.g, this is no longer necessary: [`Vec<T>`]: Vec
2020-12-07	Privatize some of libcore unicode_internals	Aleksey Kladov	-1/+1
	My understanding is that these API are perma unstable, so it doesn't make sense to pollute docs & IDE completion[1] with them. [1]: https://github.com/rust-analyzer/rust-analyzer/issues/6738
2020-07-27	mv std libs to library/	mark	-0/+576