MaybeUninit::write: fix doc
# Fix doc for `MaybeUninit::write`
The documentation refers to the way `MaybeUninit` stores data internally. The property of not dropping content on context exit is the responsibility of `ManuallyDrop`.
Add an issue template for future-incompatible lints
This adds a GitHub issue template for future-incompatible lints. Most of the existing tracking issues have been using different formats with different information, and I think it would be helpful to make them a little more consistent and to ensure that sufficient information is provided.
Some comments on my choices:
* Added a dedicated section to describe *why* the change is being made. Many existing issues already have this, so let's standardize on it.
* Have a section with a very clear example. Almost all of the existing issues have this in one form or another.
* Added a "Recommendations" section, since this is something I see missing in several of the existing issues, and this is really important information IMHO.
* I reworded the "When" section. The existing template mentioned that these get reviewed every 6 weeks which my understanding is not true. That's also not very helpful information to the user, since it doesn't really answer the question. I'm not sure this section will actually be useful since I suspect most of the time we don't know when it will change (there have been a few exceptions).
* Clearly show the expected progression steps. Several issues already have this.
* Added implementation history, which is useful for linking PRs. (IDK, this could get merged with "Steps".)
Stage0 bootstrap update
This PR [follows the release process](https://forge.rust-lang.org/release/process.html#master-bootstrap-update-tuesday) to update the stage0 compiler.
The only thing of note is 58651d1b31, which was flagged by clippy as a correctness fix. I think allowing that lint in our case makes sense, but it's worth to have a second pair of eyes on it.
r? `@Mark-Simulacrum`
Do not remove `super` keyword from `super let`
This is affecting a macro in the standard library:
bc7512ee63/library/core/src/pin.rs (L1945)
I added an exception in 6f6a9a585891d0a2d1114a7a621f35f28f39c0d9, but I'd like to remove it eventually, so opening this in-tree to not block this on the next rustfmt sync.
r? `@calebcartwright` or `@ytmimi`
cg_llvm: Clean up some inline assembly bindings
This PR combines a few loosely-related cleanups to LLVM bindings related to inline assembly. These include:
- Replacing `LLVMRustInlineAsm` with LLVM-C's `LLVMGetInlineAsm`
- Adjusting FFI declarations to avoid the need for explicit `as_c_char_ptr` conversions
- Flattening control flow in `inline_asm_call`
There should be no functional changes.
cg_llvm: Rename `OperandBundleOwned` to `OperandBundleBox`
As with `DIBuilderBox`, the "Box" suffix does a better job of communicating that this is an owning pointer to some borrowable resource.
This also renames the `raw` method to `as_ref`, which is what it would have been named originally if the `Deref` problem (#137603) had been known at the time.
No functional change.
Remove mono item collection strategy override from -Zprint-mono-items
Previously `-Zprint-mono-items` would override the mono item collection
strategy. When debugging one doesn't want to change the behaviour, so
this was counter productive. Additionally, the produced behaviour was
artificial and might never arise without using the option in the first
place (`-Zprint-mono-items=eager` without `-Clink-dead-code`). Finally,
the option was incorrectly marked as `UNTRACKED`.
Resolve those issues, by turning `-Zprint-mono-items` into a boolean
flag that prints results of mono item collection without changing the
behaviour of mono item collection.
For codegen-units test incorporate `-Zprint-mono-items` flag directly
into compiletest tool.
Test changes are mechanical. `-Zprint-mono-items=lazy` was removed
without additional changes, and `-Zprint-mono-items=eager` was turned
into `-Clink-dead-code`. Linking dead code disables internalization, so
tests have been updated accordingly.
Merge typeck loop with static/const item eval loop
r? `@ghost`
Let's try a small one first. Doing this in general has some bad cache coherence issues because the query caches are laid out in `Vec<QueryResult>` lists per query where each index refers to a `DefId` in the same order as we're iterating. Iterating two or more lists at the same time does have cache issues, so I want to poke a bit at it to see if we can't merge just a few of them at a time.
Previously `-Zprint-mono-items` would override the mono item collection
strategy. When debugging one doesn't want to change the behaviour, so
this was counter productive. Additionally, the produced behaviour was
artificial and might never arise without using the option in the first
place (`-Zprint-mono-items=eager` without `-Clink-dead-code`). Finally,
the option was incorrectly marked as `UNTRACKED`.
Resolve those issues, by turning `-Zprint-mono-items` into a boolean
flag that prints results of mono item collection without changing the
behaviour of mono item collection.
For codegen-units test incorporate `-Zprint-mono-items` flag directly
into compiletest tool.
Test changes are mechanical. `-Zprint-mono-items=lazy` was removed
without additional changes, and `-Zprint-mono-items=eager` was turned
into `-Clink-dead-code`. Linking dead code disables internalization, so
tests have been updated accordingly.
Fix linking statics on Arm64EC
Arm64EC builds recently started to fail due to the linker not finding a symbol:
```
symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol)
C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals
```
It turns out that `EMPTY_PANIC` is a new static variable that was being exported then imported from the standard library, but when exporting LLVM didn't prepend the name with `#` (as only functions are prefixed with this character), whereas Rust was prefixing with `#` when attempting to import it.
The fix is to have Rust not prefix statics with `#` when importing.
Adding tests discovered another issue: we need to correctly mark static exported from dylibs with `DATA`, otherwise MSVC's linker assumes they are functions and complains that there is no exit thunk for them.
CI found another bug: we only apply `DllImport` to non-local statics that aren't foreign items (i.e., in an `extern` block), that is we want to use `DllImport` for statics coming from other Rust crates. However, `__rust_no_alloc_shim_is_unstable` is a static generated by the Rust compiler if required, but downstream crates consider it a foreign item since it is declared in an `extern "Rust"` block, thus they do not apply `DllImport` to it and so fails to link if it is exported by the previous crate as `DATA`. The fix is to apply `DllImport` to foreign items that are marked with the `rustc_std_internal_symbol` attribute (i.e., we assume they aren't actually foreign and will be in some Rust crate).
Fixes#138541
---
try-job: dist-aarch64-msvc
try-job: dist-x86_64-msvc
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
Rollup of 8 pull requests
Successful merges:
- #140095 (Eliminate `word_and_empty` methods.)
- #140341 (Clarify black_box warning a bit)
- #140684 (Only include `dyn Trait<Assoc = ...>` associated type bounds for `Self: Sized` associated types if they are provided)
- #140707 (Structurally normalize in range pattern checking in HIR typeck)
- #140716 (Improve `-Zremap-path-scope` tests with dependency)
- #140800 (Make `rustdoc-tempdir-removal` run-make tests work on other platforms than linux)
- #140802 (Add release notes for 1.87.0)
- #140811 (Enable triagebot note functionality for rust-lang/rust)
r? `@ghost`
`@rustbot` modify labels: rollup
Only include `dyn Trait<Assoc = ...>` associated type bounds for `Self: Sized` associated types if they are provided
Since #136458, we began filtering out associated types with `Self: Sized` bounds when constructing the list of associated type bounds to put into our `dyn Trait` types. For example, given:
```rust
trait Trait {
type Assoc where Self: Sized;
}
```
After #136458, even if a user writes `dyn Trait<Assoc = ()>`, the lowered ty would have an empty projection list, and thus be equivalent to `dyn Trait`. However, this has the side effect of no longer constraining any types in the RHS of `Assoc = ...`, not implying any WF implied bounds, and not requiring that they hold when unsizing.
After this PR, we include these bounds, but (still) do not require that they are provided. If the are not provided, they are skipped from the projections list.
This results in `dyn Trait` types that have differing numbers of projection bounds. This will lead to re-introducing type mismatches e.g. between `dyn Trait` and `dyn Trait<Assoc = ()>`. However, this is expected and doesn't suffer from any of the deduplication unsoundness from before #136458.
We may want to begin to ignore thse bounds in the future by bumping `unused_associated_type_bounds` to an FCW. I don't want to tangle that up into the fix that was originally intended in #136458, so I'm doing a "fix-forward" in this PR and deferring thinking about this for the future.
Fixes#140645
r? lcnr
Tshepang Mbambo
Matthias Krüger
bors
omahs
许杰友 Jieyou Xu (Joe)
Stan Manilov
Yuki Okushi
Zalathar
Eric Huss
Tomasz Miąsko