Herein we verify that all of the tests that specify a `--target`
compile-flag, are also annotated with the minimal set of required llvm
components necessary to run that test.
Fix use placement for suggestions near main.
This fixes an edge case for the suggestion to add a `use`. When running with `--test`, the `main` function will be annotated with an `#[allow(dead_code)]` attribute. The `UsePlacementFinder` would end up using the dummy span of that synthetic attribute. If there are top-level inner attributes, this would place the `use` in the wrong position. The solution here is to ignore attributes with dummy spans.
In the process of working on this, I discovered that the `use_suggestion_placement` test was broken. `UsePlacementFinder` is unaware of active attributes. Attributes like `#[derive]` don't exist in the AST since they are removed. Fixing that is difficult, since the AST does not retain enough information. I considered trying to place the `use` towards the top of the module after any `extern crate` items, but I couldn't find a way to get a span for the start of a module block (the `mod` span starts at the `mod` keyword, and it seems tricky to find the spot just after the opening bracket and past inner attributes). For now, I just put some comments about the issue. This appears to have been a known issue in #44215 where the test for it was introduced, and the fix seemed to be deferred to later.
Due to the std/alloc split, it is not possible to make
`alloc::collections::TryReserveError::AllocError` non-exhaustive without
having an unstable, doc-hidden method to construct (which negates the
benefits from `#[non_exhaustive]`.
Permit zero non-zero-field on transparent types
Fixes#77841
This makes the transparent fields meet the below:
> * A `repr(transparent)` type `T` must meet the following rules:
> * It may have any number of 1-ZST fields
> * In addition, it may have at most one other field of type U
r? `@nikomatsakis`
Update cargo
This also updates `opener` used in bootstrap (to try to keep dependencies unified).
18 commits in 44456677b5d1d82fe981c955dc5c67734b31f340..9233aa06c801801cff75df65df718d70905a235e
2021-06-12 18:00:01 +0000 to 2021-06-22 21:32:55 +0000
- Detect incorrectly named cargo.toml (rust-lang/cargo#9607)
- Unify weak and namespaced features. (rust-lang/cargo#9574)
- Change `rustc-cdylib-link-arg` error to a warning. (rust-lang/cargo#9563)
- Updates to future-incompatible reporting. (rust-lang/cargo#9606)
- Add a compatibility notice for diesel and the new resolver. (rust-lang/cargo#9602)
- Don't allow config env to modify vars set by cargo (rust-lang/cargo#9579)
- Disambiguate is_symlink. (rust-lang/cargo#9604)
- Update opener requirement from 0.4 to 0.5 (rust-lang/cargo#9583)
- Avoid quadratic complexity when splitting output into lines (rust-lang/cargo#9586)
- Bump to 0.56.0, update changelog (rust-lang/cargo#9597)
- Fix dep-info files including non-local build script paths. (rust-lang/cargo#9596)
- Relax doc collision error. (rust-lang/cargo#9595)
- Handle "jobs = 0" case in cargo config files (rust-lang/cargo#9584)
- Enhancements to testsuite error output. (rust-lang/cargo#9589)
- Fix typo (rust-lang/cargo#9590)
- Enable support for fix --edition for 2021. (rust-lang/cargo#9588)
- Add more details for installing git repository errors (rust-lang/cargo#9582)
- More information for links conflicting (rust-lang/cargo#9568)
Support lowercase error codes in `--explain`
This enables `rustc --explain` to accept a lowercase error code. Thus, for instance, `rustc --explain e0573` would be valid after this change, where before a user would have needed to do `rustc --explain E0573`. Although the upper case form of an error code is canonical, the user may prefer the easier-to-type lowercase form, and there's nothing to be gained by forcing them to type the upper case version.
Resolves#86518.
Document associativity of iterator folds.
Document the associativity of `Iterator::fold` and
`DoubleEndedIterator::rfold` and add examples demonstrating this.
Add links to direct users to the fold of the opposite associativity.
Error code cleanup and enforce checks
Fixes#86097.
It now checks if an error code is unused, and if so, will report an error if the error code wasn't commented out in the `error_codes.rs` file. It also checks that the constant used in the tidy check is up-to-date.
r? `@Mark-Simulacrum`
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
