Commit graph

10 commits

Author SHA1 Message Date
Deadbeef
349ac4f6c8
Const Deref 2021-09-15 03:06:53 +00:00
xFrednet
d38f2b0cc1 Added diagnostic items to structs and traits for Clippy 2021-07-15 23:57:02 +02:00
John Ericson
19be438cda alloc: Add unstable Cfg feature no-global_oom_handling
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-05-05 16:49:04 -04:00
Andrea Nall
67fcaaaa7a a few more diagnostic items 2021-02-16 02:32:21 +00:00
Andrea Nall
c6bb62810a requested/proposed changes 2021-02-15 22:59:47 +00:00
Andrea Nall
5ef202520f add diagnostic items
Add diagnostic items to the following types:
  OsString (os_string_type)
  PathBuf (path_buf_type)
  Owned (to_owned_trait)

As well as the to_vec method on slice/[T]
2021-02-15 02:27:28 +00:00
Frank Steffahn
303203f992 Mention Arc::make_mut and Rc::make_mut in the documentation of Cow 2020-12-28 17:13:28 +01:00
Dylan MacKenzie
110e59e70e Update library functions with stability attributes
This may not be strictly minimal, but all unstable functions also need a
`rustc_const_unstable` attribute.
2020-09-22 10:05:58 -07:00
CDirkx
af24bdbd96 Make cow_is_borrowed methods const
Constify the following methods of `alloc::borrow::Cow`:
 - `is_borrowed`
 - `is_owned`

These methods are still unstable under `cow_is_borrowed`.
Possible because of #49146 (Allow if and match in constants).

Tracking issue: #65143
2020-08-31 03:43:47 +02:00
mark
2c31b45ae8 mv std libs to library/ 2020-07-27 19:51:13 -05:00
Renamed from src/liballoc/borrow.rs (Browse further)