bootstrap: write texts to a .tmp file first for atomicity
If you are using a hard-linked file as your config.toml, this change will affect the way other instances of the file is modified.
The original version would modify all other instances whereas the new version will leave others unchanged, reducing the ref count by one.
rustc: Search all derives for inert attributes
This commit fixes an apparent mistake in librustc_resolve where when the
`proc_macro` feature is enabled (or `rust_2018_preview`) the resolution of
custom attributes for custom derive was tweaked. Previously when an attribute
failed to resolve it was attempted to locate if there is a custom derive also in
scope which declares the attribute, but only the first custom derive directive
was search.
Instead this commit fixes the loop to search all custom derive invocations
looking for any which register the attribute in question.
Closes#52219
rustc_codegen_llvm: replace the first argument early in FnType::new_vtable.
Fixes#51907 by removing the vtable pointer before the `ArgType` is even created.
This allows any ABI to support trait object method calls, regardless of how it passes `*dyn Trait`.
r? @nikomatsakis
Rollup of 14 pull requests
Successful merges:
- #51614 (Correct suggestion for println)
- #51952 ( hygiene: Decouple transparencies from expansion IDs)
- #52193 (step_by: leave time of item skip unspecified)
- #52207 (improve error message shown for unsafe operations)
- #52223 (Deny bare trait objects in in src/liballoc)
- #52224 (Deny bare trait objects in in src/libsyntax)
- #52239 (Remove sync::Once::call_once 'static bound)
- #52247 (Deny bare trait objects in in src/librustc)
- #52248 (Deny bare trait objects in in src/librustc_allocator)
- #52252 (Deny bare trait objects in in src/librustc_codegen_llvm)
- #52253 (Deny bare trait objects in in src/librustc_data_structures)
- #52254 (Deny bare trait objects in in src/librustc_metadata)
- #52261 (Deny bare trait objects in in src/libpanic_unwind)
- #52265 (Deny bare trait objects in in src/librustc_codegen_utils)
Failed merges:
r? @ghost
Remove sync::Once::call_once 'static bound
See https://internals.rust-lang.org/t/sync-once-per-instance/7918 for more context.
Suggested r is @alexcrichton, the one who added the `'static` bound back in 2014. I don't want to officially r? though, if the system would even let me. I'd rather let the system choose the appropriate member since it knows more than I do.
`git blame` history for `sync::Once::call_once`'s signature:
- [std: Second pass stabilization of sync](f3a7ec7028) (Dec 2014)
```diff
- pub fn doit<F>(&'static self, f: F) where F: FnOnce() {
+ #[stable]
+ pub fn call_once<F>(&'static self, f: F) where F: FnOnce() {
```
- [libstd: use unboxed closures](cdbb3ca9b7) (Dec 2014)
```diff
- pub fn doit(&'static self, f: ||) {
+ pub fn doit<F>(&'static self, f: F) where F: FnOnce() {
```
- [std: Rewrite the `sync` module](71d4e77db8) (Nov 2014)
```diff
- pub fn doit(&self, f: ||) {
+ pub fn doit(&'static self, f: ||) {
```
> ```text
> The second layer is the layer provided by `std::sync` which is intended to be
> the thinnest possible layer on top of `sys_common` which is entirely safe to
> use. There are a few concerns which need to be addressed when making these
> system primitives safe:
>
> * Once used, the OS primitives can never be **moved**. This means that they
> essentially need to have a stable address. The static primitives use
> `&'static self` to enforce this, and the non-static primitives all use a
> `Box` to provide this guarantee.
> ```
The author of this diff is @alexcrichton. `sync::Once` now contains only a pointer to (privately hidden) `Waiter`s, which are all stack-allocated. The `'static` bound to `sync::Once` is thus unnecessary to guarantee that any OS primitives are non-relocatable.
As the `'static` bound is not required for `sync::Once`'s operation, removing it is strictly more useful. As an example, it allows attaching a one-time operation to instances rather than only to global singletons.
improve error message shown for unsafe operations
Add a short explanation saying why undefined behavior could arise. In particular, the error many people got for "creating a pointer to a packed field requires unsafe block" was not worded great -- it lead to people just adding the unsafe block without considering if what they are doing follows the rules.
I am not sure if a "note" is the right thing, but that was the easiest thing to add...
Inspired by @gnzlbg at https://github.com/rust-lang/rust/issues/46043#issuecomment-381544673
