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

Warn when implicitly copying polymorphic data #2449

Closed
msullivan opened this issue May 25, 2012 · 2 comments
Closed

Warn when implicitly copying polymorphic data #2449

msullivan opened this issue May 25, 2012 · 2 comments
Labels
A-type-system Area: Type system C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@msullivan
Copy link
Contributor

As part of #2431, warn when implicitly copying polymorphic data. I'm putting off doing this because I want to get an initial thing landed and don't want to fix all of the warnings for this yet.

@ghost ghost assigned msullivan May 25, 2012
@msullivan
Copy link
Contributor Author

This is actually maybe not the right thing to do... I think what we actually want to do is to shift the burden to call-sites where polymorphic functions are called with not implicitly copyable types.

@msullivan
Copy link
Contributor Author

I'm going to close this bug as wontfix, and open a new one for what we should actually do.

@msullivan msullivan removed their assignment Jun 16, 2014
bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
Use ui_test from crates.io instead of having it in-tree

I have moved a copy of the `ui_test` crate into [a separate repo](https://github.com/oli-obk/ui_test) to facilitate the further non-miri development of it. I will keep syncing until we have reached a point where we don't touch it anymore for miri. At that point we can remove the in-tree version and do further development out of tree.
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
This is a pre-work needed for implementing rust-lang#2440 as a subcommand. Today, the only other subcommand we have is assess and the way it takes arguments is rather broken as explained in rust-lang#1831.

For the playback sub-command, I expect that we will need at least CargoArgs and CommonArgs to control the build process and to control the process verbosity.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

1 participant