Improve E0308 error message wording again
Hello again,
I recently did this PR: #70242
I felt the error message could be further improved, so I made [a post on the Rust community forum](https://users.rust-lang.org/t/looking-for-feedback-on-an-improved-error-message-for-e0308/40004) to ask for feedback.
(Also, there were some comments on my original PR that I took into consideration as well.)
This PR is my attempt to take all the feedback into account and propose a better and simplified error message that should still be accurate. Its main benefit is having simpler grammar, and hopefully being easier to read and understand.
Thanks to everyone who commented and gave feedback, and thank you for taking a look at this PR.
Added detailed error code explanation for issue E0696 in Rust compiler.
Added proper error explanation for issue E0696 in the Rust compiler.
Error Code E0696
Sub Part of Issue #61137
r? @GuillaumeGomez
Suggest `-> impl Trait` and `-> Box<dyn Trait>` on fn that doesn't return
During development, a function could have a return type set that is a
bare trait object by accident. We already suggest using either a boxed
trait object or `impl Trait` if the return paths will allow it. We now
do so too when there are *no* return paths or they all resolve to `!`.
We still don't handle cases where the trait object is *not* the entirety
of the return type gracefully.
Closes#38376.
Check that main/start is not async
* Add new error code E0752
* Add span to hir::IsAsync::Yes
* Emit an error if main or the start function is marked as async
* Add two regression tests
This PR fixes#68523.
When the return type is `!Sized` we look for all the returned
expressions in the body to fetch their types and provide a reasonable
suggestion. The tail expression of the body is normally evaluated after
checking whether the return type is `Sized`. Changing the order of the
evaluation produces undesirable knock down effects, so we detect the
specific case that newcomers are likely to encounter ,returning a single
bare trait object, and only in that case we evaluate the tail
expression's type so that the suggestion will be accurate.
* Add new error code E0752
* Add span to hir::IsAsync::Yes
* Emit an error if main or the start function is marked as async
* Add two regression tests
Fix formatting errors and bless test outputs
* move tests to ui/async-await
fix test error text
remove span from IsAsync
Replace "rc"/"arc" lang items with Rc/Arc diagnostic items.
`Rc`/`Arc` should have no special semantics, so it seems appropriate for them to not be lang items.
r? @matthewjasper
Support `#[track_caller]` on functions in `extern "Rust" { ... }`
Fixes https://github.com/rust-lang/rust/issues/70830 which is the follow-up to @eddyb's suggestion in https://github.com/rust-lang/rust/pull/69251#discussion_r380791634 to allow `#[track_caller]` on `fn`s in FFI imports, that is, on functions in `extern "Rust" { ... }` blocks.
This requires that the other side, the FFI export, also have the `#[track_caller]` attribute. Otherwise, undefined behavior is triggered and the blame lies, as usual, with the `unsafe { ... }` block which called the FFI imported function.
After this PR, all forms of `fn` items with the right ABI (`"Rust"`) support `#[track_caller]`.
As a drive-by, the PR also hardens the check rejecting `#[naked] #[track_caller]` such that methods and other forms of `fn` items are also considered.
r? @eddyb
cc @rust-lang/lang
