rustdoc: remove unused JS IIFE from main.js
This [IIFE] made sense when it was added in deaf5e200e and there was a local variable scoped to it, but now it calls a function, but declares nothing.
[IIFE]: https://developer.mozilla.org/en-US/docs/Glossary/IIFE "immediately invoked function expression"
Add a detailed note for missing comma typo w/ FRU syntax
Thanks to `@pierwill` for working on this with me!
Fixes#104373, perhaps `@alice-i-cecile` can comment on the new error for the example provided on that issue -- feedback is welcome.
```
error[E0063]: missing field `defaulted` in initializer of `Outer`
--> $DIR/multi-line-fru-suggestion.rs:14:5
|
LL | Outer {
| ^^^^^ missing `defaulted`
|
note: this expression may have been misinterpreted as a `..` range expression
--> $DIR/multi-line-fru-suggestion.rs:16:16
|
LL | inner: Inner {
| ________________^
LL | | a: 1,
LL | | b: 2,
LL | | }
| |_________^ this expression does not end in a comma...
LL | ..Default::default()
| ^^^^^^^^^^^^^^^^^^^^ ... so this is interpreted as a `..` range expression, instead of functional record update syntax
help: to set the remaining fields from `Default::default()`, separate the last named field with a comma
|
LL | },
| +
error: aborting due to previous error
For more information about this error, try `rustc --explain E0063`.
```
Clarify and restrict when `{Arc,Rc}::get_unchecked_mut` is allowed.
(Tracking issue for `{Arc,Rc}::get_unchecked_mut`: #63292)
(I'm using `Rc` in this comment, but it applies for `Arc` all the same).
As currently documented, `Rc::get_unchecked_mut` can lead to unsoundness when multiple `Rc`/`Weak` pointers to the same allocation exist. The current documentation only requires that other `Rc`/`Weak` pointers to the same allocation "must not be dereferenced for the duration of the returned borrow". This can lead to unsoundness in (at least) two ways: variance, and `Rc<str>`/`Rc<[u8]>` aliasing. ([playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=d7e2d091c389f463d121630ab0a37320)).
This PR changes the documentation of `Rc::get_unchecked_mut` to restrict usage to when all `Rc<T>`/`Weak<T>` have the exact same `T` (including lifetimes). I believe this is sufficient to prevent unsoundness, while still allowing `get_unchecked_mut` to be called on an aliased `Rc` as long as the safety contract is upheld by the caller.
## Alternatives
* A less strict, but still sound alternative would be to say that the caller must only write values which are valid for all aliased `Rc`/`Weak` inner types. (This was [mentioned](https://github.com/rust-lang/rust/issues/63292#issuecomment-568284090) in the tracking issue). This may be too complicated to clearly express in the documentation.
* A more strict alternative would be to say that there must not be any aliased `Rc`/`Weak` pointers, i.e. it is required that get_mut would return `Some(_)`. (This was also mentioned in the tracking issue). There is at least one codebase that this would cause to become unsound ([here](be5a164d77/src/memtable.rs (L166)), where additional locking is used to ensure unique access to an aliased `Rc<T>`; I saw this because it was linked on the tracking issue).
If clang isn't the C compiler used for the UEFI targets, or if the wrong
`--target` is passed to clang, we will get ELF objects in some
rlibs. This will cause problems at link time when trying to compile a
UEFI program that uses any of those objects. Add a check to the dist
step for UEFI targets that reads each rlib with the `object` crate and
fails with an error if any non-COFF objects are found.
Rollup of 6 pull requests
Successful merges:
- #104537 (fix std::thread docs are unclear regarding stack sizes)
- #104558 (Don't assume `FILE_ID_BOTH_DIR_INFO` will be aligned)
- #104564 (interpret: use Either over Result when it is not representing an error condition)
- #104568 (clarify that realloc refreshes pointer provenance even when the allocation remains in-place)
- #104611 (rustdoc: use real buttons for scrape examples controls)
- #104640 (Migrate kdb style to CSS variables)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
clarify that realloc refreshes pointer provenance even when the allocation remains in-place
This [matches what C does](https://en.cppreference.com/w/c/memory/realloc):
> The original pointer ptr is invalidated and any access to it is undefined behavior (even if reallocation was in-place).
Cc `@rust-lang/wg-allocators`
Check fat pointer metadata compatibility modulo regions
Regions don't really mean anything anyways during hir typeck.
If this `erase_regions` makes anyone nervous, it's probably equally valid to just equate the types using a type relation, but regardless we should _not_ be using strict type equality while region variables are present.
Fixes#103384
make miri-seed a regular integer, and also set layout-seed in many-seeds
This makes the seed format consistent between `-Zlayout-seed` and `-Zmiri-seed`.
Rollup of 6 pull requests
Successful merges:
- #103901 (Add tracking issue for `const_arguments_as_str`)
- #104112 (rustdoc: Add copy to the description of repeat)
- #104435 (`VecDeque::resize` should re-use the buffer in the passed-in element)
- #104467 (Fix substraction with overflow in `wrong_number_of_generic_args.rs`)
- #104608 (Cleanup macro matching recovery)
- #104626 (Fix doctest errors related to rustc_middle)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
