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
pubstructS<constN:usize>{pubx:[u32;N]}pubfnf(y:[u32;1]) -> S<1>{S{x: y }}pubfng(y:[u32;2]) -> S<2>{S{x: y }}
The f and g functions return two different instantiations of the S struct. While S<1> and S<2> look distinct at the source level, they are not so distinct at the MIR level:
Both occurrences of S are represented as ADTs with their const parameter instantiated with nonty::Const. This is a challenge for tools like SAW, which look up ADTs in a type-directed way. One might imagine writing something like this to look up S<1> or S<2>:
mir_find_adt m "test::S" [mir_const];
Where mir_const represents nonty::Const. The problem is that this is ambiguous, as it could refer to bothS<1> and S<2>. Moreover, the JSON doesn't provide a straightforward way to tell which ADT was instantiated with <1> and which was instantiated with <2>.
I propose that we change the representation of nonty::Const to also include the particular constant that was used for the instantiation. That way, SAW users could write something like:
mir_find_adt m "test::S" [mir_const {{ 1 }}];
mir_find_adt m "test::S" [mir_const {{ 2 }}];
MIR's GenericArgKind::Const should provide all the information necessary to encode this constant information.
The text was updated successfully, but these errors were encountered:
Consider this code:
The
f
andg
functions return two different instantiations of theS
struct. WhileS<1>
andS<2>
look distinct at the source level, they are not so distinct at the MIR level:Both occurrences of
S
are represented as ADTs with their const parameter instantiated withnonty::Const
. This is a challenge for tools like SAW, which look up ADTs in a type-directed way. One might imagine writing something like this to look upS<1>
orS<2>
:Where
mir_const
representsnonty::Const
. The problem is that this is ambiguous, as it could refer to bothS<1>
andS<2>
. Moreover, the JSON doesn't provide a straightforward way to tell which ADT was instantiated with<1>
and which was instantiated with<2>
.I propose that we change the representation of
nonty::Const
to also include the particular constant that was used for the instantiation. That way, SAW users could write something like:MIR's
GenericArgKind::Const
should provide all the information necessary to encode this constant information.The text was updated successfully, but these errors were encountered: