-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't require Drop
for [PhantomData<T>; N]
where N
and T
are generic, if T
requires Drop
#115527
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @cjgillot (or someone else) soon. Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (
|
cc @fee1-dead |
cc @lcnr you assigned yourself on my PR |
r? @lcnr |
this breaks struct NeedsDrop;
impl Drop for NeedsDrop {
fn drop(&mut self) {
println!("dropping");
}
}
struct Foo<const N: usize>([NeedsDrop; N]);
struct Bar(Foo<0>);
const fn should_not_drop(x: Bar) {}
fn main() {
should_not_drop(Bar(Foo([])));
} |
a72f9da
to
d268d53
Compare
|
||
debug!("needs_drop_raw({:?}) = {:?}", query, res); | ||
res | ||
} | ||
|
||
/// HACK: in order to mistakenly assume that `[PhantomData<T>; N]` requires drop glue |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
something someething missing negation 😁
/// HACK: in order to mistakenly assume that `[PhantomData<T>; N]` requires drop glue | |
/// HACK: in order to not mistakenly assume that `[PhantomData<T>; N]` requires drop glue |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me after adding the test for the above regression
huh I had that test locally... I fail at git |
…generic, if `T` requires `Drop`
d268d53
to
320bb81
Compare
@bors r=lcnr |
☀️ Test successful - checks-actions |
Finished benchmarking commit (1e746d7): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResultsThis 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 sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 628.819s -> 627.948s (-0.14%) |
note: this was also picked up in crater (https://crater-reports.s3.amazonaws.com/beta-1.73-1.2/beta-2023-09-10/reg/construe-0.0.3/log.txt), looks like it's already beta-nominated though. |
…k-Simulacrum [beta] backport This PR backports: - rust-lang#115785: Only suggest turbofish in patterns if we may recover - rust-lang#115527: Don't require `Drop` for `[PhantomData<T>; N]` where `N` and `T` are generic, if `T` requires `Drop` - rust-lang#115389: fix(resolve): update def if binding is warning ambiguity - rust-lang#115215: Remove assert that checks type equality r? `@Mark-Simulacrum`
fixes #115403
fixes #115410
This was accidentally regressed in #114134, because it was accidentally stabilized in #102204 (cc @rust-lang/lang, seems like an innocent stabilization, considering this PR is more of a bugfix than a feature).
While we have a whole month to beta backport this change before the regression hits stable, I'd still prefer not to go through an FCP on this PR (which fixes a regression), if T-lang wants an FCP, I can can open an issue about the change itself.