Check whether the closure's owner is an ADT in thir-unsafeck
This pull request fixes#85871. The code in `rustc_mir_build/src/check_unsafety.rs` incorrectly assumes that a closure's owner always has a body, but only functions, closures, and constants have bodies, whereas a closure can also appear inside a struct or enum:
```rust
struct S {
arr: [(); match || 1 { _ => 42 }]
}
enum E {
A([(); { || 1; 42 }])
}
```
This pull request fixes the resulting ICE by checking whether the closure's owner is an ADT and only deferring to `thir_check_unsafety(owner)` if it isn't.
Fix crate filter search reset
I found a fun bug when using rustdoc recently: I made a search, cut the search input content, changed the crate filter, pasted back the input content. To my surprise, the crate filter wasn't applied. It's because that our search input was empty when receiving the `<select>` "onchange" event. To fix this issue, I reset the `currentResults` variable to `null`.
It's using the first commit from #86542 so it needs to wait for it before getting merged.
r? `@jsha`
Better errors for Debug and Display traits
Currently, if someone tries to pass value that does not implement `Debug` or `Display` to a formatting macro, they get a very verbose and confusing error message. This PR changes the error messages for missing `Debug` and `Display` impls to be less overwhelming in this case, as suggested by #85844. I was a little less aggressive in changing the error message than that issue proposed. Still, this implementation would be enough to reduce the number of messages to be much more manageable.
After this PR, information on the cause of an error involving a `Debug` or `Display` implementation would suppressed if the requirement originated within a standard library macro. My reasoning was that errors originating from within a macro are confusing when they mention details that the programmer can't see, and this is particularly problematic for `Debug` and `Display`, which are most often used via macros. It is possible that either a broader or a narrower criterion would be better. I'm quite open to any feedback.
Fixes#85844.
Rollup of 6 pull requests
Successful merges:
- #86223 (Specify the kind of the item for E0121)
- #86521 (Add comments around code where ordering is important due for panic-safety)
- #86523 (Improvements to intra-doc link macro disambiguators)
- #86542 (Line numbers aligned with content)
- #86549 (Add destructuring example of E0508)
- #86557 (Update books)
Failed merges:
- #86548 (Fix crate filter search reset)
r? `@ghost`
`@rustbot` modify labels: rollup
Line numbers aligned with content
We had the issue a few times in the past where the source code pages' content wasn't aligned with the line numbers but completely below. This test will prevent this change to go unnoticed.
The first commit comes from https://github.com/rust-lang/rust/pull/86541 so it needs it to be merged first.
r? `@jsha`
Improvements to intra-doc link macro disambiguators
A few small improvements around macro disambiguators:
- display the link text as it was entered: previously `[macro!()]` would be displayed without the parantheses (fixes#86309)
- support `!{}` and `![]` as macro disambiguators (fixes#86310)
r? `@jyn514` cc `@Manishearth` `@camelid`
Add comments around code where ordering is important due for panic-safety
Iterators contain arbitrary code which may panic. Unsafe code has to be
careful to do its state updates at the right point between calls that may panic.
As requested in https://github.com/rust-lang/rust/pull/86452#discussion_r655153948
r? `@RalfJung`
Re-add support for parsing (and pretty-printing) inner-attributes in match body
Re-add support for parsing (and pretty-printing) inner-attributes within body of a `match`.
In other words, we can do `match EXPR { #![inner_attr] ARM_1 ARM_2 ... }` again.
I believe this unbreaks the only four crates that crater flagged as broken by PR #83312.
(I am putting this up so that the lang-team can check it out and decide whether it changes their mind about what to do regarding PR #83312.)
Fix emit path hashing
With `--emit KIND=PATH`, the PATH should not affect hashes used for dependency tracking. It does not with other ways of specifying output paths (`-o` or `--out-dir`).
Also updates `rustc -Zls` to print more info about crates, which is used here to implement a `run-make` test.
It seems there was already a test explicitly checking that `OutputTypes` hash *is* affected by the path. I think this behaviour is wrong, so I updated the test.
Iterators contain arbitrary code which may panic. Unsafe code has to be
careful to do its state updates at the right point between calls
that may panic.
Disambiguate between SourceFiles from different crates even if they have the same path
This PR fixes an ICE that can occur when the compiler encounters a source file that is part of both the local crate and an upstream crate:
1. While importing source files from an upstream crate the compiler creates a `SourceFile` entry for `foo.rs` in the `SourceMap`. Since this is an imported source file its `src` field is `None`.
2. At a later point the parser encounters `foo.rs` again. It tells the `SourceMap` to load the file but because we already have an entry for `foo.rs` the `SourceMap` will return the existing version with `src == None`.
3. The parser proceeds under the assumption that `src.is_some()` and panics when actually trying to use the file's contents.
This PR fixes the issue by adding the source file's associated `CrateNum` to the `SourceMap`'s interning key. As a consequence the two instances of the file will each have a separate entry in the `SourceMap`. They just happen to share the same file path. This approach seemed less problematic to me than trying to mutate the `SourceFile` after it had already been created.
Another, more involved, approach might be to merge the `src` and the `external_src` field.
Fixes#85955
Mark some edition tests as check-pass
## Overview
This helps with #62277. In short, there are some tests that were marked as `build-pass` when it was unclear whether `check-pass` might be more appropriate. This PR marks some of those tests as `compile-pass`, in addition to making some incidental formatting improvements.
## A brief explanation of why this is correct
These tests fall into a few buckets.
`src/test/ui/dyn-keyword/dyn-2015-edition-keyword-ident-lint.rs`
`src/test/ui/dyn-keyword/dyn-2015-idents-in-decl-macros-unlinted.rs`
`src/test/ui/dyn-keyword/dyn-2015-idents-in-macros-unlinted.rs`
`src/test/ui/dyn-keyword/dyn-2015-no-warnings-without-lints.rs`
`src/test/ui/dyn-keyword/issue-56327-dyn-trait-in-macro-is-okay.rs`
These test a lint for a keyword added in a new edition and the corresponding changes in keyword rules.
`src/test/ui/editions/edition-feature-ok.rs`
This checks that a feature related to an edition transition is valid.
`src/test/ui/editions/edition-imports-virtual-2015-ambiguity.rs`
This checks that imports between editions work correctly.
`src/test/ui/editions/edition-keywords-2015-2015-expansion.rs`
`src/test/ui/editions/edition-keywords-2018-2015-expansion.rs`
This checks the interaction between a change in keyword status over editions and macros.
All of the things being tested come before linking and codegen, so it is safe to use `check-pass` for them.
Fix `unused_unsafe` around `await`
Enables `unused_unsafe` lint for `unsafe { future.await }`.
The existing test for this is `unsafe { println!() }`, so I assume that `println!` used to contain compiler-generated unsafe but this is no longer true, and so the existing test is broken. I replaced the test with `unsafe { ...await }`. I believe `await` is currently the only instance of compiler-generated unsafe.
Reverts some parts of #85421, but the issue predates that PR.
Cleanup handling of `crate_name` for doctests
- Remove unnecessary reallocation
- Remove unnecessary messing around with `queries` for the crate name; it's simpler and faster to go through the TyCtxt instead
- Rename `cratename` -> `crate_name` for consistency with the rest of the compiler
rustdoc: add optional woff2 versions of Source Serif and Source Code
This provides woff2 versions of Source Serif and Source Code similar to how #82545 provides woff2 versions of Fira Sans. The total byte count for the six files (three for each font family) is reduced by 25% from 476 KiB to 358 KiB.
