clarify wording of match ergonomics diagnostics (`rust_2024_incompatible_pat` lint and error)
Partially addresses rust-lang/rust#143557:
- Uses different wording than the Edition Guide chapter, to hopefully stand alone a bit better. Instead of referring to the "default binding mode", it now talks about what can't be written "within elided reference patterns". I ended up going with "elided" instead of "implicit" in hope that it reads bit less like it should behave the same as an explicit reference pattern, but I'm not totally happy with that wording.
- The explanatory note still points to where the default binding mode was introduced, but only refers to its effect, not what we call it. How that relates to the rest of the diagnostic may still be a bit of a puzzle, but hopefully it isn't too much of one? It also doesn't make sense anymore for the case of `&` written under a by-ref binding mode, so I've left the note out in that case (but kept the label). It's more cramped, but talking about binding modes would feel like a non-sequitur for the error about `&` patterns without further explanation.
- Links to the stable version of the Edition Guide instead of the nightly version. It looks like almost every link to the Edition Guide in diagnostics is to the nightly version, presumably for the same reason as here: the diagnostics were added before the new Edition was stabilized, then never updated. I'll make a separate PR to clean up the others.
This only changes the diagnostic messages, not the code suggestion or the Edition Guide.
r? `@Nadrieril` or reassign
sort attribute targets for more consistent error messages
In this PR I noticed that we don't sort attribute targets, so a rather trivial change to the source changed the ordering in an error message even though its meaning stayed the same.
See: https://github.com/rust-lang/rust/pull/147418#discussion_r2410852750
I think sorting might be a good thing to do in general. I also prefer it when reading error messages. Quite a few tests changed, but not in meaning, only sorting order obviously.
r? `@jieyouxu`
Use globals instead of metadata for std::autodiff
LLVM's Metadata is quite fragile. In debug builds we use incremental compilation, which caused the metadata to be dropped. With this change we use named globals instead of metadata to instruct Enzyme how to differentiate functions.
Globals are proper llvm values and thus can't be dropped. Also added an incremental/dbg test which now passes, to unblock the EnzymeAD CI which wants to run Rust autodiff tests.
r? compiler
rename `select_where_possible` and `select_all_or_error`
r? `@lcnr`
I find that people get confused by what these methods do. The verb "select" is not really that helpful and is just a reference to somewhat of an implementation detail of the trait solvers that doesn't even apply to most obligation kinds.
I went with `try_evaluate_obligations` and `evaluate_obligations_error_on_ambiguity`. This maintains consistency with the new solvers `evalute_goal` entry point. it's unfortunate that we say obligations rather than goals but this maintains consistency with `register_obligation` functions which I think is a good thing. In the long term possibly we rename `Obligation` or `Goal` 🤷♀️
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#146865 (kcfi: only reify trait methods when dyn-compatible)
- rust-lang/rust#147205 (Add a new `wasm32-wasip3` target to Rust)
- rust-lang/rust#147322 (cg_llvm: Consistently import `llvm::Type` and `llvm::Value`)
- rust-lang/rust#147398 (Fix; correct placement of type inference error for method calls)
- rust-lang/rust#147410 (Update `S-waiting-on-team` refs to new `S-waiting-on-{team}` labels)
- rust-lang/rust#147422 (collect-license-metadata: Print a diff of the expected output)
- rust-lang/rust#147431 (compiletest: Read the whole test file before parsing directives)
- rust-lang/rust#147433 (Fix doc comment)
Failed merges:
- rust-lang/rust#147390 (Use globals instead of metadata for std::autodiff)
r? `@ghost`
`@rustbot` modify labels: rollup
Add a new `wasm32-wasip3` target to Rust
This commit adds a new tier 3 target to rustc, `wasm32-wasip3`. This follows in the footsteps of the previous `wasm32-wasip2` target and is used to represent binding to the WASIp3 set of APIs managed by the WASI subgroup to the WebAssembly Community Group.
As of now the WASIp3 set of APIs are not finalized nor standardized. They're in the process of doing so and the current trajectory is to have the APIs published in December of this year. The goal here is to get the wheels turning in Rust to have the target in a
more-ready-than-nonexistent state by the time this happens in December.
For now the `wasm32-wasip3` target looks exactly the same as `wasm32-wasip2` except that `target_env = "p3"` is specified. This indicates to crates in the ecosystem that WASIp3 APIs should be used, such as the [`wasip3` crate]. Over time this target will evolve as implementation in guest toolchains progress, notably:
* The standard library will use WASIp3 APIs natively once they're finalized in the WASI subgroup.
* Support through `wasi-libc` will be updated to use WASIp3 natively which Rust will then transitively use.
* Longer-term, features such as cooperative multithreading will be added to the WASIp3-track of targets to enable using `std::thread`, for example, on this target.
These changes are all expected to be non-breaking changes for users of this target. Runtimes supporting WASIp3, currently Wasmtime and Jco, support WASIp2 APIs as well and will work with components whether or not they import WASIp2, both WASIp2 and WASIp3, or just WASIp3 APIs. This means that changing the internal implementation details of libstd over time is expected to be a non-breaking change.
[`wasip3` crate]: https://crates.io/crates/wasip3
kcfi: only reify trait methods when dyn-compatible
fixes https://github.com/rust-lang/rust/issues/146853
Only generate a `ReifyShim` for trait method calls if the trait is dyn-compatible.
Until now kcfi would generate a `ReifyShim` whenever a trait method was cast to a function pointer. But technically the shim is only needed for dyn-compatible traits (where the method might end up in a vtable).
Up to this point that was only slightly inefficient, but in combination with c-variadic trait methods it is wrong. For c-variadic trait methods the generated shim is incorrect, and that is why c-variadic methods make a trait no longer dyn-compatible: we should simply never generate a `ReifyShim` that is c-variadic.
With this change the documentation on `ReifyReason` is now actually correct:
> If KCFI is enabled, creating a function pointer from a method on a dyn-compatible trait. This includes the case of converting `::call`-like methods on closure-likes to function pointers.
cc ```@maurer``` ```@workingjubilee```
r? ```@rcvalle```
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#145943 (stdlib docs: document lifetime extension for `format_args!`'s arguments)
- rust-lang/rust#147243 (cmse: disallow `impl Trait` in `cmse-nonsecure-entry` return types)
- rust-lang/rust#147402 ([rustdoc] Don't serialize & deserialize data that doesn't go OTW)
- rust-lang/rust#147418 (Fix target list of `link_section`)
- rust-lang/rust#147429 (Print tip for human error format in runtest)
- rust-lang/rust#147441 (Fix comments error for Provenance impls)
- rust-lang/rust#147442 (c-variadic: fix thir-print for `...` without a pattern)
r? `@ghost`
`@rustbot` modify labels: rollup
cmse: disallow `impl Trait` in `cmse-nonsecure-entry` return types
tracking issue: https://github.com/rust-lang/rust/issues/75835
fixes https://github.com/rust-lang/rust/issues/147242
Refactors some logic to be more robust in the future, and then disallows `impl Trait` as a return type for the cmse ABIs.
The `is_valid_cmse_output_layout` function disallows `union` values like before. That is not entirely correct, but preserves the current behavior. Some additional logic is needed for `union` values (and any types where parts may be uninitialized) that I'll tackle in a later PR.
can be reviewed commit-by-commit.
r? types
Prevent downstream `impl DerefMut for Pin<LocalType>`
The safety requirements for [`PinCoerceUnsized`](https://doc.rust-lang.org/stable/std/pin/trait.PinCoerceUnsized.html) are essentially that the type does not have a malicious `Deref` or `DerefMut` impl. However, the `Pin` type is fundamental, so the end-user can provide their own implementation of `DerefMut` for `Pin<&SomeLocalType>`, so it's possible for `Pin` to have a malicious `DerefMut` impl. This unsoundness is known as rust-lang/rust#85099.
Unfortunately, this means that the implementation of `PinCoerceUnsized` for `Pin` is currently unsound. To fix that, modify the impl so that it becomes impossible for downstream crates to provide their own implementation of `DerefMut` for `Pin` by abusing a hidden struct that is not fundamental.
This PR is a breaking change, but it fixesrust-lang/rust#85099. The PR supersedes rust-lang/rust#144896.
r? lcnr
don't panic on extern with just multiple quotes in the name
Continues rust-lang/rust#147377.
That PR fixed ICE when the extern name was a single quote `"'"`, but multiple quotes like `"''"` cause the same problem.
I had a random revelation that the trimming can remove more than one quote.
r? ``@nnethercote``
Improve diagnostics: update note and add help message
I moved the content from the note to a help message, as it seemed more appropriate there, and then added new information to the note(`Modules are usually placed outside of blocks, at the top level of the file`)!
resolve: rust-lang/rust#147314
test: Subtract code_offset from width for ui_testing
`annotate-snippets` does not have a "UI test" mode like `rustc`, [where the code offset is not subtracted from the column width](f34ba774c7/compiler/rustc_errors/src/emitter.rs (L1985-L1987)). This makes it so `annotate-snippets` will shift the output for some very long tests 5 - 7 columns to the left. As part of my work to have `rustc` use `annotate-snippets`, and to reduce the test differences between the two, I figured it would be best if `rustc` started subtracting the code offset from the width as well.
The first commit exists to keep the test output changes of adding a new line to a test separate from adding the `--diagnostic-width` flag in the second commit. This makes it easier to verify that adding the flag does not affect the test's output.
[Zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/147480-t-compiler.2Fdiagnostics/topic/annotate-snippets.20hurdles)
support link modifier `as-needed` for raw-dylib-elf
This pull request:
* emits `-Wl,--as-needed` instead of `-Wl,--no-as-needed` for `raw-dylib-elf`, keeping it consistent with `dylib`
* allows combination of link kind `raw-dylib` and link modifier `as-needed`, thus allowing free choice of behavior
r? `@bjorn3`
cc https://github.com/rust-lang/rust/issues/135694
cc https://github.com/rust-lang/rust/issues/99424
ignore power alignment rule on unions
fixes https://github.com/rust-lang/rust/issues/147348
The power alignment rule only applies to the non-first field of a struct, and so should not apply to unions at all.
The current code also does not consider enums (whose fields might be, morally, structs). Given that C does not actually have ADTs like this it's probably fine from a compatibility perspective, but I'll leave that to the powerpc folks.
cc `@daltenty` `@gilamn5tr`
r? compiler
Do not assert that a change in global cache only happens when concurrent
Fixesrust-lang/trait-system-refactor-initiative#234
I think it should just be safe to remove this assert (rather than delaying a bug). If the previous and current result are the same, I wouldn't expect issues.
r? lcnr
