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

Made type and value enums clone- and copy-able. #22

Merged
merged 8 commits into from Oct 26, 2017
Merged

Conversation

71
Copy link
Contributor

@71 71 commented Oct 25, 2017

Description

Added #[derive(Clone, Copy)] to AnyValueEnum, AggregateValueEnum, BasicValueEnum, BasicMetadataValueEnum, BasicTypeEnum and AnyTypeEnum.

Related Issue

Fixes #14.

Motivation and Context

Allows values and types (which are opaque pointers) to be copied and cloned at will.

How Has This Been Tested?

Existing tests have been run without a problem. The change is implemented by the Rust compiler, and shouldn't cause any issue.

Types of Changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Required

  • My code follows the code style of this project
  • I have added or updated documentation (and doc tests) to any new or changed functions or types
  • I have added tests to cover my changes
  • All new and existing tests passed

Desired

  • I have ran clippy and updated portions of code pertaining to my changes (Shouldn't be needed, since I added two keywords. Also Clippy doesn't compile on my machine).

@codecov
Copy link

codecov bot commented Oct 25, 2017

Codecov Report

Merging #22 into master will decrease coverage by 0.53%.
The diff coverage is 4.87%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #22      +/-   ##
==========================================
- Coverage   53.71%   53.17%   -0.54%     
==========================================
  Files          35       37       +2     
  Lines        3742     3780      +38     
==========================================
  Hits         2010     2010              
- Misses       1732     1770      +38
Impacted Files Coverage Δ
src/values/traits.rs 0% <0%> (ø)
src/types/traits.rs 0% <0%> (ø)
src/types/enums.rs 30% <100%> (ø) ⬆️
src/values/enums.rs 31.5% <3.57%> (-17.43%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 322cf13...db6f82c. Read the comment docs.

@TheDan64
Copy link
Owner

While we're at it, we should probably add Copy + Clone to the super traits?

@TheDan64 TheDan64 self-requested a review October 25, 2017 19:44
@71
Copy link
Contributor Author

71 commented Oct 25, 2017

Mhm, such as the following snippet?

pub trait AnyType: AsTypeRef + Debug + Clone + Copy { }

In any case, I'd like to remove pub impl $trait_name from the macros we're using right now, in order to add doc comments to every trait.

@TheDan64
Copy link
Owner

Yup, I think that should suffice for both macros

@71
Copy link
Contributor Author

71 commented Oct 25, 2017

Welp, that's not gonna be possible...
Adding Clone or Copy requires the passed object to be Sized, which also means that any function accepting AnyType or AnyValue (for example) will no longer compile.

There are two solutions:

  • Use generic functions (fn do_something<V: BasicValue>(value: &V) instead of fn do_something(value: &BasicValue)), which means that all existing function will be generated multiple times in the produced binary for a single purpose;
  • Do not implement Copy or Clone.

Your thoughts?

@TheDan64
Copy link
Owner

Generics are preferable to trait objects in almost all situations due to it being a compile time cost. The one case I can think of where trait objects are required is when we have input of mixed types (ie function parameters for one). We definitely can't get rid of those. So I guess we should just leave it out.

Maybe later we can add a Trait <-> Enum mapping which allows us to convert between them, which would allow you to clone. But for now this should suffice. Please be sure to add Debug at the very least.

Copy link
Owner

@TheDan64 TheDan64 left a comment

Choose a reason for hiding this comment

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

I think this looks good overall. I left one comment.

It would be great to have the trait definitions remain in the macro, but I think that would require procedural macros. I'll create a "cleanup" issue for it and leave it for much later

@@ -22,6 +22,30 @@ macro_rules! trait_value_set {
);
}

/// Represents an aggregate value, built on top of other values.
pub trait AggregateValue: AnyValue {
Copy link
Owner

Choose a reason for hiding this comment

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

I think this should be pub trait AggregateValue: BasicValue? Since AggregateValue is a subset of BasicValue?

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 yep, good catch. I'll fix this as soon as I can. No other problem to fix here?

Copy link
Owner

Choose a reason for hiding this comment

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

I'll give it one final look before I merge, but I did not see anything else

/// Represents any LLVM type.
pub trait AnyType: AsTypeRef + Debug {
/// Returns an `AnyTypeEnum` that represents the current type.
fn as_any_type_enum(&self) -> AnyTypeEnum {
Copy link
Owner

@TheDan64 TheDan64 Oct 26, 2017

Choose a reason for hiding this comment

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

It's interesting to note that these look a little bit like associated types, though not exactly the same

Copy link
Contributor Author

Choose a reason for hiding this comment

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

They kind of do, although not in a generic way

@TheDan64 TheDan64 merged commit b75c231 into TheDan64:master Oct 26, 2017
@TheDan64
Copy link
Owner

Thanks for the PR!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Types & Values should be Copy + Clone
2 participants