Co-authored-by: Bastian Kauschke <bastian_kauschke@hotmail.de>

…unction

Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>

This commit makes the JSON emitter use `-Z terminal-width` in the
"rendered" field of the JSON output.

Signed-off-by: David Wood <david@davidtw.co>

Normally, we encode a `Span` that references a foreign `SourceFile` by
encoding information about the foreign crate. When we decode this
`Span`, we lookup the foreign crate in order to decode the `SourceFile`.

However, this approach does not work for proc-macro crates. When we load
a proc-macro crate, we do not deserialzie any of its dependencies (since
a proc-macro crate can only export proc-macros). This means that we
cannot serialize a reference to an upstream crate, since the associated
metadata will not be available when we try to deserialize it.

This commit modifies foreign span handling so that we treat all foreign
`SourceFile`s as local `SourceFile`s when serializing a proc-macro.
All `SourceFile`s will be stored into the metadata of a proc-macro
crate, allowing us to cotinue to deserialize a proc-macro crate without
needing to load any of its dependencies.

Since the number of foreign `SourceFile`s that we load during a
compilation session may be very large, we only serialize a `SourceFile`
if we have also serialized a `Span` which requires it.

`fs::DirEntry::metadata` doesn't traverse symlinks. It is not immediately
clear what to do if you do want to traverse symlinks. This change adds
links to the two other `metadata` functions that will follow symlinks.

Added io forwarding methods to the stdio structs

Added methods to forward the `io::Read` and `io::Write` methods of the myriad wrapper structs in `stdio.rs` to their underlying readers / writers. This is especially important for the structs on the outside of a locking boundary, to ensure that the lock isn't being dropped and re-acquired in a loop.

…ewjasper

MIR sanity check: validate types on assignment

This expands the MIR validation added by @jonas-schievink in rust-lang#72093 to also check that on an assignment, the types of both sides match.

Cc @eddyb @oli-obk

…Amanieu

Add documentation to point to `File::open` or `OpenOptions::open` instead of `is_file` to check read/write possibility

Fixes rust-lang#64170.

This adds documentation to point user towards `!is_dir` instead of `is_file` when all they want to is read from a source.

I ran `rg "fn is_file\("` to find all `is_file` methods, I hope I did not miss one.

Adds a clearer message for when the async keyword is missing from a f…

…unction

This is a somewhat simple fix for rust-lang#66731.

Under the current version of Rust, if a user has a rust file that looks like this:

```rust
fn boo (){}

async fn foo() {
    boo().await;
}

fn main() {

}
```

And they attempt to run it, they will receive an error message that looks like this:

```bash
error: incorrect use of `await`                                                                                                        --> test.rs:4:14                                                                                                                       |                                                                                                                                   4 |     boo.await();                                                                                                                    |              ^^ help: `await` is not a method call, remove the parentheses                                                                                                                                                                                              error[E0277]: the trait bound `fn() {boo}: std::future::Future` is not satisfied                                                        --> test.rs:4:5                                                                                                                        |                                                                                                                                  4  |     boo.await();                                                                                                                    |     ^^^^^^^^^ the trait `std::future::Future` is not implemented for `fn() {boo}`                                                                                                                                                                                      error: aborting due to 2 previous errors                                                                                                                                                                                                                                    For more information about this error, try `rustc --explain E0277`.
```

This is not very clear.

With the changes made in this PR, when a user compiles and runs that same rust code, they will receive an error message that looks like this:

```bash
error[E0277]: `()` is not a future.
 --> test.rs:4:5
  |
4 |     boo().await;
  |     ^^^^^^^^^^^ `()` is not a future
  |
  = help: the trait `std::future::Future` is not implemented for `()`
  = note: required by `std::future::Future::poll`
```

In the future, I think we should make this error message even clearer, perhaps through a solution like the one described in [this comment](rust-lang#66731 (comment)). However, as that potentially involves a major change proposal, I would rather get this change in now and make the error message a little clearer while an MCP is drafted and discussed.

Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>

…an, r=petrochenkov

Serialize all foreign `SourceFile`s into proc-macro crate metadata

Normally, we encode a `Span` that references a foreign `SourceFile` by
encoding information about the foreign crate. When we decode this
`Span`, we lookup the foreign crate in order to decode the `SourceFile`.

However, this approach does not work for proc-macro crates. When we load
a proc-macro crate, we do not deserialzie any of its dependencies (since
a proc-macro crate can only export proc-macros). This means that we
cannot serialize a reference to an upstream crate, since the associated
metadata will not be available when we try to deserialize it.

This commit modifies foreign span handling so that we treat all foreign
`SourceFile`s as local `SourceFile`s when serializing a proc-macro.
All `SourceFile`s will be stored into the metadata of a proc-macro
crate, allowing us to cotinue to deserialize a proc-macro crate without
needing to load any of its dependencies.

Since the number of foreign `SourceFile`s that we load during a
compilation session may be very large, we only serialize a `SourceFile`
if we have also serialized a `Span` which requires it.

…er, r=estebank

errors: use `-Z terminal-width` in JSON emitter

This PR makes the JSON emitter use `-Z terminal-width` in the "rendered" field of the JSON output.

r? @estebank

replace more `DefId`s with `LocalDefId`

part of rust-lang#70853

fix typo in self-profile.md

Forward Hash::write_iN to Hash::write_uN

The `Hasher::write_iN()` methods should forward to `Hasher::write_uN()`, because some Hasher implementations implement only the `write_uN()` variants, with the expectation that `write_iN()` will use the same implementation. Most notably, this is the case for the [FxHasher](https://github.com/rust-lang/rustc-hash/blob/5e09ea0a1c7ab7e4f9e27771f5a0e5a36c58d1bb/src/lib.rs#L111) used by rustc itself.

This used to be the case previously, but was broken in rust-lang#59982. As the PR description makes no mention of this particular change, I assume it was unintentional.

In a local test, this mitigates the regression from rust-lang#73526 on at least one test-case (cc @cuviper), because we're no longer at the mercy of `FxHasher::write()` getting inlined to get reasonable performance.

…-metadata, r=hanna-kruppe

Add links to fs::DirEntry::metadata

`fs::DirEntry::metadata` doesn't traverse symlinks. It is not immediately clear what to do if you do want to traverse symlinks. This change adds links to the two other `metadata` functions that will follow symlinks.