transpile: Translate enums with newtype structs#1620
transpile: Translate enums with newtype structs#1620Rua wants to merge 1 commit intoimmunant:masterfrom
Conversation
Rua
changed the title
Rua
force-pushed
the
enum-struct
branch
6 times, most recently
from
1fd4b08 to
908acb1
Compare
|
It seems that the transpiler is generating working code, but then the refactorer is breaking the imports. I don't know if that's simply a bug in the refactorer, or something else. Edit: wondering if the refactorer is not handling |
Rua
force-pushed
the
enum-struct
branch
2 times, most recently
from
20ee393 to
54595eb
Compare
|
The errors from refactor don't seem to have gone away. This PR hasn't changed anything about refactor, so is that a bug in the refactorer? |
kkysen
left a comment
kkysen
left a comment
There was a problem hiding this comment.
The errors from refactor don't seem to have gone away. This PR hasn't changed anything about refactor, so is that a bug in the refactorer?
Oh sorry, I meant #1623 should help make the error messages legible, but not fix them.
This is likely either a bug in the refactorer, or the refactorer is assuming something about what code the transpiler generates for enums and now can't handle a different translation of enums. If it's the latter, we should probably fix it here.
|
I've not looked at the refactorer code at all yet, so I wouldn't really know where to look for a possible cause. The CI error messages don't give much of a hint. |
@ahomescu, do you have any idea maybe? |
|
Could you share the refactorer errors you're getting? |
|
The errors are happening in CI. I can't run the tests on NixOS myself. |
Rua
force-pushed
the
enum-struct
branch
3 times, most recently
from
1064aa6 to
797e7a0
Compare
|
I've removed the second commit from the PR, the one that uses associated constants instead of global ones. That seems to be the one that the refactorer has trouble with. EDIT: I guess not? Hmm. |
|
If you run the transpiler with |
|
@ahomescu Doesn't seem so. Enabling it on #[derive(Clone, Copy)]
#[repr(transparent)]
#[c2rust::src_loc = "2:1"]
pub struct E(pub ::core::ffi::c_uint);
#[c2rust::src_loc = "4:5"]
pub const B: E = E(1);
#[c2rust::src_loc = "3:5"]
pub const A: E = E(0); |
Rua
force-pushed
the
enum-struct
branch
2 times, most recently
from
80aa3fa to
9098794
Compare
Rua
force-pushed
the
enum-struct
branch
18 times, most recently
from
64c7af3 to
d816c96
Compare
|
Finally managing to get all the CI to pass, with a bunch of dependencies to fix the blocking issues. |
| void TypeEncoder::VisitEnumType(const EnumType *T) { | ||
| auto ed = T->getDecl()->getDefinition(); | ||
|
|
||
| if (!ed) { |
There was a problem hiding this comment.
Could you use stacked PRs to make this easier to review? I already looked at these lines in the other PR. Thanks!
There was a problem hiding this comment.
On second thought, do we support stacked PRs in our repo? It seems the feature is not public yet.
There was a problem hiding this comment.
I haven't seen that feature anywhere yet.
…nize_definitions` (#1744) - Fixes #1660 Constructors for tuple/unit structs have a separate ID from their parent item, so they need to be included or calls to those constructors are not renamed. There may be more issues like this in other parts of the refactorer, but these fixes were enough to get #1620 to pass the tests.
kkysen
left a comment
kkysen
left a comment
There was a problem hiding this comment.
All of the dependency PRs have been merged now, so could you rebase?
Rua
force-pushed
the
enum-struct
branch
2 times, most recently
from
fb6007e to
faf9bae
Compare
3 participants
RenameUnnamedandreorganize_definitions#1744prune_unwanted_declsonly after settingprenamed_decls#1739CastKind::from_types#1737