The only regression is one ambiguity in the new trait solver, having to
do with two param-env candidates that may apply. I think this is fine,
since the error message already kinda sucks.
Update cargo
12 commits in 0c14026aa84ee2ec4c67460c0a18abc8519ca6b2..dead4b8740c4b6a8ed5211e37c99cf81d01c3b1c
2023-06-14 18:43:05 +0000 to 2023-06-20 20:07:17 +0000
- Convert valid feature name warning to an error. (rust-lang/cargo#12291)
- fix(embedded): Don't pollute script dir with lockfile (rust-lang/cargo#12284)
- fix: remove `-Zjobserver-per-rustc` again (rust-lang/cargo#12285)
- docs: some tweaks around `cargo test` (rust-lang/cargo#12288)
- Enable `doctest-in-workspace` by default (rust-lang/cargo#12221)
- fix(embedded): Don't auto-discover build.rs files (rust-lang/cargo#12283)
- fix(embeded): Don't pollute the scripts dir with `target/` (rust-lang/cargo#12282)
- feat: prepare for the next lockfile bump (rust-lang/cargo#12279)
- fix(embedded): Don't create an intermediate manifest (rust-lang/cargo#12268)
- refactor(embedded): Switch to `syn` for parsing doc comments (rust-lang/cargo#12258)
- fix(embedded): Align package name sanitization with cargo-new (rust-lang/cargo#12255)
- Clarify the default behavior of cargo-install. (rust-lang/cargo#12276)
r? `@ghost`
Revert #112758 and add test case
Fixes#112831.
Cannot unwrap `update_resolution` for `resolution.single_imports.remove(&Interned::new_unchecked(import));` because there is a relationship between the `Import` and `&NameBinding` in `NameResolution`. This issue caused by my unfamiliarity with the data structure and I apologize for it.
This PR had been reverted, and test case have been added.
r? `@Nilstrieb`
cc `@petrochenkov`
Rollup of 6 pull requests
Successful merges:
- #112464 (Fix windows `Socket::connect_timeout` overflow)
- #112720 (Rustdoc: search: color item type and reduce size to avoid clashing)
- #112762 (Sort the errors from arguments checking so that suggestions are handled properly)
- #112786 (change binders from tuple structs to named fields)
- #112794 (Fix linker failures when #[global_allocator] is used in a dependency)
- #112819 (Disable feature(unboxed_closures, fn_traits) in weird-exprs)
r? `@ghost`
`@rustbot` modify labels: rollup
Sort the errors from arguments checking so that suggestions are handled properly
Fixes#112507
The algorithm of `find_issue` does not make sure the index comes out in order, which will make suggesting `remove` or `add` arguments broken in some cases.
Modifying the algorithm to obey order involves much more trivial change, so it's better to order the `errors` after iterations.
Rustdoc: search: color item type and reduce size to avoid clashing
- rustdoc: search: color item type same as item
- rustdoc: search: reduce item type size to 0.875rem to avoid clashing with path and item
Add `implement_via_object` to `rustc_deny_explicit_impl` to control object candidate assembly
Some built-in traits are special, since they are used to prove facts about the program that are important for later phases of compilation such as codegen and CTFE. For example, the `Unsize` trait is used to assert to the compiler that we are able to unsize a type into another type. It doesn't have any methods because it doesn't actually *instruct* the compiler how to do this unsizing, but this is later used (alongside an exhaustive match of combinations of unsizeable types) during codegen to generate unsize coercion code.
Due to this, these built-in traits are incompatible with the type erasure provided by object types. For example, the existence of `dyn Unsize<T>` does not mean that the compiler is able to unsize `Box<dyn Unsize<T>>` into `Box<T>`, since `Unsize` is a *witness* to the fact that a type can be unsized, and it doesn't actually encode that unsizing operation in its vtable as mentioned above.
The old trait solver gets around this fact by having complex control flow that never considers object bounds for certain built-in traits:
2f896da247/compiler/rustc_trait_selection/src/traits/select/candidate_assembly.rs (L61-L132)
However, candidate assembly in the new solver is much more lovely, and I'd hate to add this list of opt-out cases into the new solver. Instead of maintaining this complex and hard-coded control flow, instead we can make this a property of the trait via a built-in attribute. We already have such a build attribute that's applied to every single trait that we care about: `rustc_deny_explicit_impl`. This PR adds `implement_via_object` as a meta-item to that attribute that allows us to opt a trait out of object-bound candidate assembly as well.
r? `@lcnr`
Rollup of 8 pull requests
Successful merges:
- #112232 (Better error for non const `PartialEq` call generated by `match`)
- #112499 (Fix python linting errors)
- #112596 (Suggest correct signature on missing fn returning RPITIT/AFIT)
- #112606 (Alter `Display` for `Ipv6Addr` for IPv4-compatible addresses)
- #112781 (Don't consider TAIT normalizable to hidden ty if it would result in impossible item bounds)
- #112787 (Add gha problem matcher)
- #112799 (Clean up "doc(hidden)" check)
- #112803 (Format the examples directory of cg_clif)
r? `@ghost`
`@rustbot` modify labels: rollup
