Skip to content
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

const forget tests #69645

Merged
merged 3 commits into from
Mar 11, 2020
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions src/libcore/tests/lib.rs
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,7 @@
#![feature(never_type)]
#![feature(unwrap_infallible)]
#![feature(leading_trailing_ones)]
#![feature(const_forget)]

extern crate test;

Expand Down
18 changes: 18 additions & 0 deletions src/libcore/tests/mem.rs
Original file line number Diff line number Diff line change
Expand Up @@ -129,3 +129,21 @@ fn test_discriminant_send_sync() {
is_send_sync::<Discriminant<Regular>>();
is_send_sync::<Discriminant<NotSendSync>>();
}

#[test]
fn test_const_forget() {
const _: () = forget(0i32);
const _: () = forget(Vec::<Vec<Box<i32>>>::new());

// Writing this function signature without const-forget
// triggers compiler errors:
// 1) That we use a non-const fn inside a const fn
// 2) without the forget, it complains about the destructor of Box
const fn const_forget_box<T>(x: Box<T>) {
forget(x);
}

// Call the forget_box at runtime,
// as we can't const-construct a box yet.
const_forget_box(Box::new(0i32));
Copy link
Member

@RalfJung RalfJung Mar 16, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test fails in Miri due to a memory leak: it complains that there is a (run-time!) allocation that did not get freed, and that allocation is the Box being created here.

It almost looks like that is deliberate? Do we really want a leaking test in the test suite? Cc @oli-obk

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't entirely see the point of calling this function at run-time, as it tests nothing about CTFE. Sure, you can't test it at compile-time, but testing at run-time instead makes no sense, it just tests the entirely wrong thing. Am I missing something?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh woops, I'm sory, I didn't thought of this failing miri. (Why did the CI still succeed, btw? no miri test?)
The runtime call was more like a 'Proof' it still works at runtime. It can be removed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Due to CI budget constraints, running Miri on the libcore test suite is a separate project. That's why CI here did not fail.

It can be removed.

I would prefer that. Can you submit a PR?

}