-
Notifications
You must be signed in to change notification settings - Fork 277
Fix the reorganize_definitions refactoring #1364
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
base: master
Are you sure you want to change the base?
Conversation
f0c9f2a
to
5d6a751
Compare
b0a8be1
to
a3464ac
Compare
e527293
to
7968d29
Compare
cae38e2
to
da612cb
Compare
7968d29
to
17261ed
Compare
da612cb
to
073e366
Compare
1720b7c
to
5c20a5e
Compare
4a917b1
to
b998b55
Compare
657816b
to
7f25d95
Compare
36fd226
to
c351a8f
Compare
7f25d95
to
28e3158
Compare
c351a8f
to
71e9d3d
Compare
28e3158
to
1fb194a
Compare
71e9d3d
to
c42bdd0
Compare
3b6b204
to
0f281b4
Compare
0f281b4
to
e715943
Compare
e715943
to
6aa13a0
Compare
e3fb41a
to
c717e17
Compare
6aa13a0
to
6d527b1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Several questions inline; everything else looks good.
ModKind::Loaded(_items, Inline::Yes, _spans) => { | ||
// TODO: handle #[path="..."] | ||
} | ||
|
||
ModKind::Loaded(_items, Inline::No, _spans) => { | ||
// We shouldn't be seeing any loaded modules at this point | ||
panic!("unexpected loaded module: {i:?}"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The conjunction of these two comments is confusing: are inline modules not considered loaded modules (such that we might see them)? Or is it that specifically we shouldn't see any non-inline loaded modules yet?
// TODO: we still should assert here | ||
//assert!(old_id.is_none(), "span {ns:?} already has id {old_id:?} != {id:?}"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this TODO
be addressed before merging, or is there a reason it can't be addressed yet?
// We need a separate kind for ExprKind::Path because | ||
// the rustc macro expander emits `*foo` expressions where | ||
// both the outer and inner expressions have the same span | ||
// We disambiguate by assigning (span, Expr) to the outer one, | ||
// and (span, PathExpr) to the inner expression. | ||
PathExpr, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this similar to the span_fix
module that driver.rs
claims (in a 6-year-old comment) we should be using?
6d527b1
to
8edb5f0
Compare
c717e17
to
2ec9dfd
Compare
8edb5f0
to
b6d2c9e
Compare
2ec9dfd
to
7bd3b4e
Compare
b6d2c9e
to
cd518be
Compare
7bd3b4e
to
a77dce1
Compare
cd518be
to
9804b07
Compare
a77dce1
to
51fbbcd
Compare
"id {id:?} already has span {old_ns:?} != {ns:?}" | ||
); | ||
// Some spans can show up in multiple nodes | ||
//assert!(old_id.is_none(), "span {ns:?} already has id {old_id:?} != {id:?}"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this redundant?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh this is old_id
not old_ns
, nevermind.
// Intentionally skip PathSegment to avoid collisions | ||
Some(Node::Ty(ty)) => Some(NodeSpan::new(ty.span, Ty)), | ||
// We do not have a SpanNodeKind for TyBinding | ||
// We do not have a SpanNodeKind for TraitRef | ||
Some(Node::Pat(pat)) => Some(NodeSpan::new(pat.span, Pat)), | ||
Some(Node::Arm(arm)) => Some(NodeSpan::new(arm.span, Arm)), | ||
Some(Node::Block(block)) => Some(NodeSpan::new(block.span, Block)), | ||
// We do not have a SpanNodeKind for Ctor | ||
// We do not have a SpanNodeKind for Lifetime | ||
// We do not have a SpanNodeKind for GenericParam | ||
// We do not have a SpanNodeKind for Infer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are the comments for other Node
variants? It might make more sense then to keep the individual matches => None
instead of _ => None
.
_ => {} | ||
} | ||
match (self.cx.try_resolve_ty(ty1), self.cx.try_resolve_ty(ty1)) { | ||
match (self.cx.try_resolve_ty(ty1), self.cx.try_resolve_ty(ty2)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was this just a typo before?
#[macro_export] | ||
macro_rules! match_or_else { | ||
([$e:expr] $($arm_pat:pat => $arm_body:expr),*; $or_else:expr) => { | ||
match $e { | ||
$( $arm_pat => $arm_body, )* | ||
ref x @ _ => $or_else(x), | ||
} | ||
}; | ||
} | ||
|
||
#[macro_export] | ||
macro_rules! expect { | ||
([$e:expr] $arm_pat:pat => $arm_body:expr) => { | ||
$crate::match_or!([$e] $arm_pat => $arm_body; | ||
panic!("expected {}", stringify!($arm_pat))) | ||
$crate::match_or_else!([$e] $arm_pat => $arm_body; | ||
|x| panic!("expected {}, got {:?}", stringify!($arm_pat), x)) | ||
}; | ||
([$e:expr] $($arm_pat:pat => $arm_body:expr),*) => { | ||
$crate::match_or!([$e] $($arm_pat => $arm_body),*; | ||
panic!("expected one of: {}", stringify!($($arm_pat),*))) | ||
$crate::match_or_else!([$e] $($arm_pat => $arm_body),*; | ||
|x| panic!("expected one of: {}, got {:?}", stringify!($($arm_pat),*), x)) | ||
}; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do we need this for? Especially if it's not used, I'd rather not add to expect!
given that assert_matches!
does the same and is much more standardized.
let Item { | ||
ref mut attrs, | ||
ref span, | ||
ref ident, | ||
kind: ItemKind::Mod(_, ref mut mod_kind), | ||
.. | ||
} = *i else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let Item { | |
ref mut attrs, | |
ref span, | |
ref ident, | |
kind: ItemKind::Mod(_, ref mut mod_kind), | |
.. | |
} = *i else { | |
let Item { | |
attrs, | |
span, | |
ident, | |
kind: ItemKind::Mod(_, mod_kind), | |
.. | |
} = &mut *i else { |
// Look for dir_path/foo.rs, then try dir_path/foo/mod.rs | ||
let mut mod_file_path = self.dir_path.join(ident.as_str()).with_extension("rs"); | ||
if !self.source_map.file_exists(&mod_file_path) { | ||
mod_file_path = self.dir_path.join(ident.as_str()).with_file_name("mod.rs"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't do ${dir_path}/${ident}/mod.rs
, it does ${dir_path}/mod.rs
.
pub node_id_to_span_map: HashMap<NodeId, NodeSpan>, | ||
pub span_to_node_id_map: HashMap<NodeSpan, NodeId>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we use HashMap
sometimes and FxHashMap
other times?
Some fixes to the
reorganize_definitions
transform for c2rust-refactor to make it work again.