Update the error message for a missing global allocator
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.
NLL diagnostics: revise `fn check_access_permissions`
NLL: revise `fn check_access_permissions` so that its (still branchy) shares more code paths between the different cases, and also provide more diagnostics in more cases (though the added diagnostics still do not always meet the quality bar established by AST-borrowck)
----
Transcribing "checklist" suggested by Niko, except I am rendering it as a table to make it clear that I do not regard every item in the list to be a "must have" for landing this PR.
goal | does this PR do it?
-----|------------------------------
no suggestions for `ref mut` | yes
suggestions for direct local assignment (`{ let x = 3; x = 4; }`) | yes (see commits at end)
suggestions for direct field assignment (`{ let x = (3, 4); x.0 = 5; }` | yes (see commits at end)
suggestions for upvars (`let x = 3; let c = \|\| { &mut x; }`) | yes
Note that I added support for a couple of rows via changes that are not strictly part of `fn check_access_permissions`. If desired I can remove those commits from this PR and leave them for a later PR.
Fix#51031Fix#51032
(bug #51191 needs a little more investigation before closing.)
Fix#51578
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.
