Rollup of 12 pull requests #133561
Merged
Rollup of 12 pull requests #133561
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Include warning about losing setuid/gid when chowning, per POSIX.
Linked to chown(2) manpage on the web which expands on chown call behaviour.
Co-authored-by: Urgau <3616612+Urgau@users.noreply.github.com>
…in collect_return_position_impl_trait_in_trait_tys
…', and '<*mut [T]>::as_mut_array' conversion methods;
Now that `HashSet::entry()` exists, we don't need to fake it with a map.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Expand std::os::unix::fs::chown() doc with a warning Include warning about losing setuid/gid when chowning, per POSIX. It is about the underlying system call but it is rather useful to mention it in the help in case someone accidentally forgets (don't look at me :)).
Add release notes for Rust 1.83.0 Issues: https://github.com/rust-lang/rust/issues?q=is%3Aissue%20state%3Aopen%20label%3Arelnotes-tracking-issue%20milestone%3A1.83.0 r? `@Mark-Simulacrum` cc `@rust-lang/release`
…onstrained-params, r=lcnr Delay a bug when encountering an impl with unconstrained generics in `codegen_select` Despite its name, `codegen_select` is what powers `Instance::try_resolve`, which is used in pre-codegen contexts to try to resolve a method where possible. One place that it's used is in the "recursion MIR lint" that detects recursive MIR bodies. If we encounter an impl in `codegen_select` that contains unconstrained generic parameters, we expect that impl to caused an error to be reported; however, there's no temporal guarantee that this error is reported *before* we call `codegen_select`. This is what a delayed bug is *for*, and this PR makes us use a delayed bug rather than asserting something about errors already having been emitted. Fixes rust-lang#126646
…lcnr Actually use placeholder regions for trait method late bound regions in `collect_return_position_impl_trait_in_trait_tys` So in rust-lang#113182, I introduced a "diagnostics improvement" in the form of 473c88d, which changes which signature we end up instantiating with placeholder regions and which signature we end up instantiating with fresh region vars so that we have placeholders corresponding to the names of the late-bound regions coming from the *impl*. However, this is not sound, since now we're essentially no longer proving that *all* instantiations of the trait method are compatible with an instantiation of the impl method, but vice versa (which is weaker). Let's look at the example `tests/ui/impl-trait/in-trait/do-not-imply-from-trait-impl.rs`: ```rust trait MkStatic { fn mk_static(self) -> &'static str; } impl MkStatic for &'static str { fn mk_static(self) -> &'static str { self } } trait Foo { fn foo<'a: 'static, 'late>(&'late self) -> impl MkStatic; } impl Foo for str { fn foo<'a: 'static>(&'a self) -> impl MkStatic + 'static { self } } fn call_foo<T: Foo + ?Sized>(t: &T) -> &'static str { t.foo().mk_static() } fn main() { let s = call_foo(String::from("hello, world").as_str()); println!("> {s}"); } ``` To collect RPITITs, we were previously instantiating the trait signature with infer vars (`fn(&'?0 str) -> ?1t` where `?1t` is the variable we use to infer the RPITIT) and the impl signature with placeholders (there are no late-bound regions in that signature, so we just have `fn(&'a str) -> Opaque`). Equating the signatures works, since all we do is unify `?1t` with `Opaque` and `'?0` with `'a`. However, conceptually it *shouldn't* hold, since this definition is not valid for *all* instantiations of the trait method but just the one where `'0` (i.e. `'late`) is equal to `'a` :( ## So what This PR effectively reverts 473c88d to fix the unsoundness. Fixes rust-lang#133427 Also fixes rust-lang#133425, which is actually coincidentally another instance of this bug (but not one that is weaponized into UB, just one that causes an ICE in refinement checking).
Add `as_array` and `as_mut_array` conversion methods to slices. Tracking issue: rust-lang#133508 This PR unstably implements the `as_array` and `as_mut_array` converters to `[T]`, `*const [T]`, and `*mut [T]`.
Check `xform_ret_ty` for WF in the new solver to improve method winnowing
This is a bit interesting. Method probing in the old solver is stronger than the new solver because eagerly normalizing types causes us to check their corresponding trait goals. This is important because we don't end up checking all of the where clauses of a method when method probing; just the where clauses of the impl. i.e., for:
```
impl Foo
where
WC1,
{
fn method()
where
WC2,
{}
}
```
We only check WC1 and not WC2. This is because at this point in probing the method is instantiated w/ infer vars, and checking the where clauses in WC2 will lead to cycles if we were to check them (at least that's my understanding; I could investigate changing that in general, incl. in the old solver, but I don't have much confidence that it won't lead to really bad overflows.)
This PR chooses to emulate the old solver by just checking that the return type is WF. This is theoretically stronger, but I'm not too worried about it. I think we alternatively have several approaches we can take here, though this one seems the simplest. Thoughts?
r? lcnr
…ve-mir-borrowck, r=lcnr Structurally resolve before applying projection in borrowck As far as I can tell, all other `.normalize` calls in borrowck are noops and can remain that way. This is the only one that actually requires structurally resolving the type. r? lcnr
extend group-forbid-always-trumps-cli test Test it not just for a lint group, but also an individual lint, or when mixing the lint and the group. And test both orders in which the flags could be passed.
…=GuillaumeGomez [rustdoc] Fix new clippy lints Lots of small things that clippy lints about. r? `@fmease`
rustc_span: Replace a `HashMap<_, ()>` with `HashSet` Now that `HashSet::entry()` exists, we don't need to fake it with a map.
print generated doc paths Resolves rust-lang#133002
rustbot
added
A-rustdoc-json
|
@bors r+ p=10 rollup=never |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: eddb717281 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Nov 28, 2024
|
Finished benchmarking commit (f005c74): comparison URL. Overall result: ❌ regressions - please read the text belowOur benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -4.5%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResults (primary -0.6%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResults (primary 0.0%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 795.273s -> 792.58s (-0.34%) |
|
The regressions in the primary benchmarks reverted back to their previous mean after a few PRs so I don't think this is necessarily worth looking further into. @rustbot label: +perf-regression-triaged |
rustbot
added
the
perf-regression-triaged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
codegen_select#133368 (Delay a bug when encountering an impl with unconstrained generics incodegen_select)collect_return_position_impl_trait_in_trait_tys#133428 (Actually use placeholder regions for trait method late bound regions incollect_return_position_impl_trait_in_trait_tys)as_arrayandas_mut_arrayconversion methods to slices. #133512 (Addas_arrayandas_mut_arrayconversion methods to slices.)xform_ret_tyfor WF in the new solver to improve method winnowing #133519 (Checkxform_ret_tyfor WF in the new solver to improve method winnowing)HashMap<_, ()>withHashSet#133547 (rustc_span: Replace aHashMap<_, ()>withHashSet)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup