Rename OOM to allocation error
The acronym is not descriptive unless one has seen it before.
* Rename the `oom` function to `handle_alloc_error`. It was **stabilized in 1.28**, so if we do this at all we need to land it this cycle.
* Rename `set_oom_hook` to `set_alloc_error_hook`
* Rename `take_oom_hook` to `take_alloc_error_hook`
Bikeshed: `on` v.s. `for`, `alloc` v.s. `allocator`, `error` v.s. `failure`
Don’t mention `#[default_lib_allocator]` (which is an implementation detail
irrelevant to most users) and instead suggest using `#[global_allocator]`,
which is often the correct fix.
(since I made this mistake at first but the tests didn't catch it):
we should not suggest adding `mut` to a reassigned `ref` or `ref mut` binding.
(The Rust language, since at least 1.0, does not have `mut ref mut` or
`ref mut mut` etc.)
Tried to unify various common code paths and also vaguely approximate
the AST-borrowck diagnostics.
The change in (subjective) quality of diagnostics is not a universal
improvement. But I think this is a better code base to work from
for future fixes.
Namely, we thread down the `HirId` of the explicit type of the
argument. In the case of the special `self` variable with an implicit
type, we also thread down a description of its structure (`self`/`mut
self`/`&self`/`&mut self`).
As a drive-by: the ref_for_guards created by `fn declare_binding`
should not have been tagged as user_variables in the first
place. These secret internal locals are *pointers* to user variables,
but themselves are not such (IMO. For now at least.)
the originally generated code was highly suboptimal
this brings it close to the same code or even exactly the same as a
manual while-loop by eliminating a branch and the
double stepping of n-1 + 1 steps
The intermediate trait lets us circumvent the specialization
type inference bugs
Use String, not &str in some collection examples
Discussed in #46966
Overuse of borrowed values in data structures is a common mistake I see in Rust user forums. Users who copy&paste such examples end up fighting with the borrow checker as soon as they replace string literals with some real values.
This changes a couple of examples to use `String`, and it adds opportunity to demonstrate use of `Borrow`.
Add ability to apply custom derive to union types.
The Union item type has been included in the allowed types for a custom derive.
fyi @abonander
Closes#50223
`has_any_child_of` is hot. It allocates a `Vec` that almost always
doesn't exceed a length of 1.
This patch peels off the first iteration of the loop, avoiding the need
for the `Vec` creation in ~99% of cases.
The acronym is not descriptive unless one has seen it before.
* Rename the `oom` function to `handle_alloc_error`. It was **stabilized in 1.28**, so if we do this at all we need to land it this cycle.
* Rename `set_oom_hook` to `set_alloc_error_hook`
* Rename `take_oom_hook` to `take_alloc_error_hook`
Bikeshed: `alloc` v.s. `allocator`, `error` v.s. `failure`
Improve memoization and refactor NLL type check
I have a big branch that is refactoring NLL type check with the goal of introducing canonicalization-based memoization for all of the operations it does. This PR contains an initial prefix of that branch which, I believe, stands alone. It does introduce a few smaller optimizations of its own:
- Skip operations that are trivially a no-op
- Cache the results of the dropck-outlives computations done by liveness
- Skip resetting unifications if nothing changed
r? @pnkfelix
Add existential type definitions
Note: this does not allow creating named existential types, it just desugars `impl Trait` to a less (but still very) hacky version of actual `existential type` items.
r? @nikomatsakis
impl Hash for !
This was missing in some generic code I was writing and I figured that it would be worthwhile to add this. Blanket-requiring these traits to allow usage of errors in `HashSet`s and `HashMap`s isn't too unreasonable of a use case, and a prerequisite for allowing `!` as an error in such situations is this impl.
libstd: add an RAII utility for sys_common::mutex::Mutex
It is indeed debatable whether or not we should introduce more sophistication like this to the lowest layer of a system library. In fact, `Drop::drop()` cannot be `unsafe` (IIRC there was a discussion on introducing an unsafe variant of `Drop` whose entire scope must be within `unsafe`)
Removed two unused variables in os.rs
Issue #51419 suggested removing two unused variables in `libstd/sys/redox/os.rs`. This PR implements that change.
It compiles for me locally, but I haven't run any other tests.
