You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've recently added a bunch of builtin types and traits, and a lot of tests associated with them. We should decide whether we're organizing tests by the trait the implement, or the type that implements.
Right now, there are some tests in test/builtin_impls, but much more in test/*. For example, there is test/builtin_impl/copy.rs which has only the test for tuples being copy. All the other Copy-related tests are in separate files. For example, fn_def_is_copy is in test/fn_def.rs.
I somewhat think that Unsize might be different. The tests are somewhat complicated, and I would feel better about being able to reason about the same logic across different types. Additionally, we can somewhat justify this since these tests are really testing the conversion of one type to another.
Somewhat related to this, it might be nice to go through and document why we have each test (as well as the individual goals in each test). Though, I'm not sure if that should be a part of this issue or a separate issue.
The text was updated successfully, but these errors were encountered:
We've recently added a bunch of builtin types and traits, and a lot of tests associated with them. We should decide whether we're organizing tests by the trait the implement, or the type that implements.
Right now, there are some tests in
test/builtin_impls
, but much more intest/*
. For example, there istest/builtin_impl/copy.rs
which has only the test for tuples being copy. All the otherCopy
-related tests are in separate files. For example,fn_def_is_copy
is intest/fn_def.rs
.I imagine it'll be easiest to just have each type be a separate file, so testing for
Copy
,Clone
,WF
, etc. would all be in one file. This would roughly line up with each row in http://rust-lang.github.io/chalk/book/clauses/well_known_traits.html being in a separate file.I somewhat think that
Unsize
might be different. The tests are somewhat complicated, and I would feel better about being able to reason about the same logic across different types. Additionally, we can somewhat justify this since these tests are really testing the conversion of one type to another.Somewhat related to this, it might be nice to go through and document why we have each test (as well as the individual goals in each test). Though, I'm not sure if that should be a part of this issue or a separate issue.
The text was updated successfully, but these errors were encountered: