Inter-Procedural Analysis by ebepho · Pull Request #4 · rad-rust/rust

ebepho · 2026-06-04T15:48:21Z

Changed the pass to an initial interprocedural report. It now starts from a protected root, walks the reachable call tree, separates local vs external calls, and prints the formal inputs for functions reached inside the protected region.

The implementation is organized as two stages:

Local MIR summary pass: records each function’s formal args, callsites, return source, and simple local provenance.
Interprocedural propagation/report pass: starts from #[rad_protected], walks reachable calls, binds caller actuals to callee, and reports sources/absolute sources.

Tested on test_startracker():

=== Protected Function Analysis ===
Protected root: test_startracker
Reached functions:
- test_startracker
- tests::startracker::startracker
- std::iter::IntoIterator::into_iter (external)
- std::iter::Iterator::next (external)
- rand::random (external)
- core::fmt::rt::Argument::<'_>::new_debug (external)
- std::fmt::Arguments::<'a>::new (external)
- std::io::_print (external)
- libm::sqrtf (external)
Call tree:
test_startracker
├── tests::startracker::startracker
├── std::iter::IntoIterator::into_iter (external)
├── std::iter::Iterator::next (external)
└── libm::sqrtf (external)
├── std::io::_print (external)
├── std::iter::IntoIterator::into_iter (external)
├── std::iter::Iterator::next (external)
├── core::fmt::rt::Argument::<'_>::new_debug (external)
├── std::fmt::Arguments::<'a>::new (external)
└── rand::random (external)
Inputs:
tests::startracker::startracker._1: &[f32; 4]
source: test_startracker._23
absolute_source: test_startracker._23
tests::startracker::startracker._2: &[f32; 4]
source: test_startracker._25
absolute_source: test_startracker._25
tests::startracker::startracker._3: &mut [f32; 6]
source: test_startracker._27
absolute_source: test_startracker._27
std::iter::IntoIterator::into_iter._1: Self
std::iter::Iterator::next._1: &mut Self
source: unknown
absolute_source: unknown
libm::sqrtf._1: f32
std::io::_print._1: std::fmt::Arguments<'_>
std::iter::IntoIterator::into_iter._1: Self
std::iter::Iterator::next._1: &mut Self
source: unknown
absolute_source: unknown
core::fmt::rt::Argument::<'_>::new_debug._1: &T
source: unknown
absolute_source: unknown
std::fmt::Arguments::<'a>::new._1: &'a [u8; N]
source: unknown
absolute_source: unknown
std::fmt::Arguments::<'a>::new._2: &'a [core::fmt::rt::Argument<'a>; M]
source: unknown
absolute_source: unknown
Outputs:
test_startracker._0
tests::startracker::startracker._0

h313

Good work! We should iterate a bit on our DFS and cycle detection approach.

h313 · 2026-06-05T15:04:17Z

+ }
+
+ while let Some(caller) = worklist.pop() {
+ if !visited.insert(caller) {


What happens if the same function gets called by two different functions? Would it make sense to process each function call individually?

h313 · 2026-06-05T15:07:57Z

+ continue;
+ };
+
+ for callsite in &caller_summary.callsites {


What happens if we have call the same function multiple times? Would it make sense to record each one as separate function calls in our summary, or should we have the summary output just once for each function?

ebepho · 2026-06-04T15:48:21Z

Changed the pass to an initial interprocedural report. It now starts from a protected root, walks the reachable call tree, separates local vs external calls, and prints the formal inputs for functions reached inside the protected region.

The implementation is organized as two stages:

Local MIR summary pass: records each function’s formal args, callsites, return source, and simple local provenance.
Interprocedural propagation/report pass: starts from #[rad_protected], walks reachable calls, binds caller actuals to callee, and reports sources/absolute sources.

Tested on test_startracker():

=== Protected Function Analysis ===
Protected root: test_startracker
Reached functions:
- test_startracker
- tests::startracker::startracker
- std::iter::IntoIterator::into_iter (external)
- std::iter::Iterator::next (external)
- rand::random (external)
- core::fmt::rt::Argument::<'_>::new_debug (external)
- std::fmt::Arguments::<'a>::new (external)
- std::io::_print (external)
- libm::sqrtf (external)
Call tree:
test_startracker
├── tests::startracker::startracker
├── std::iter::IntoIterator::into_iter (external)
├── std::iter::Iterator::next (external)
└── libm::sqrtf (external)
├── std::io::_print (external)
├── std::iter::IntoIterator::into_iter (external)
├── std::iter::Iterator::next (external)
├── core::fmt::rt::Argument::<'_>::new_debug (external)
├── std::fmt::Arguments::<'a>::new (external)
└── rand::random (external)
Inputs:
tests::startracker::startracker._1: &[f32; 4]
source: test_startracker._23
absolute_source: test_startracker._23
tests::startracker::startracker._2: &[f32; 4]
source: test_startracker._25
absolute_source: test_startracker._25
tests::startracker::startracker._3: &mut [f32; 6]
source: test_startracker._27
absolute_source: test_startracker._27
std::iter::IntoIterator::into_iter._1: Self
std::iter::Iterator::next._1: &mut Self
source: unknown
absolute_source: unknown
libm::sqrtf._1: f32
std::io::_print._1: std::fmt::Arguments<'_>
std::iter::IntoIterator::into_iter._1: Self
std::iter::Iterator::next._1: &mut Self
source: unknown
absolute_source: unknown
core::fmt::rt::Argument::<'_>::new_debug._1: &T
source: unknown
absolute_source: unknown
std::fmt::Arguments::<'a>::new._1: &'a [u8; N]
source: unknown
absolute_source: unknown
std::fmt::Arguments::<'a>::new._2: &'a [core::fmt::rt::Argument<'a>; M]
source: unknown
absolute_source: unknown
Outputs:
test_startracker._0
tests::startracker::startracker._0

h313

Good work! We should iterate a bit on our DFS and cycle detection approach.

h313 · 2026-06-05T15:04:17Z

+ }
+
+ while let Some(caller) = worklist.pop() {
+ if !visited.insert(caller) {


What happens if the same function gets called by two different functions? Would it make sense to process each function call individually?

h313 · 2026-06-05T15:07:57Z

+ continue;
+ };
+
+ for callsite in &caller_summary.callsites {


What happens if we have call the same function multiple times? Would it make sense to record each one as separate function calls in our summary, or should we have the summary output just once for each function?

ebepho · 2026-06-04T15:48:21Z

Changed the pass to an initial interprocedural report. It now starts from a protected root, walks the reachable call tree, separates local vs external calls, and prints the formal inputs for functions reached inside the protected region.

The implementation is organized as two stages:

Local MIR summary pass: records each function’s formal args, callsites, return source, and simple local provenance.
Interprocedural propagation/report pass: starts from #[rad_protected], walks reachable calls, binds caller actuals to callee, and reports sources/absolute sources.

Tested on test_startracker():

=== Protected Function Analysis ===
Protected root: test_startracker
Reached functions:
- test_startracker
- tests::startracker::startracker
- std::iter::IntoIterator::into_iter (external)
- std::iter::Iterator::next (external)
- rand::random (external)
- core::fmt::rt::Argument::<'_>::new_debug (external)
- std::fmt::Arguments::<'a>::new (external)
- std::io::_print (external)
- libm::sqrtf (external)
Call tree:
test_startracker
├── tests::startracker::startracker
├── std::iter::IntoIterator::into_iter (external)
├── std::iter::Iterator::next (external)
└── libm::sqrtf (external)
├── std::io::_print (external)
├── std::iter::IntoIterator::into_iter (external)
├── std::iter::Iterator::next (external)
├── core::fmt::rt::Argument::<'_>::new_debug (external)
├── std::fmt::Arguments::<'a>::new (external)
└── rand::random (external)
Inputs:
tests::startracker::startracker._1: &[f32; 4]
source: test_startracker._23
absolute_source: test_startracker._23
tests::startracker::startracker._2: &[f32; 4]
source: test_startracker._25
absolute_source: test_startracker._25
tests::startracker::startracker._3: &mut [f32; 6]
source: test_startracker._27
absolute_source: test_startracker._27
std::iter::IntoIterator::into_iter._1: Self
std::iter::Iterator::next._1: &mut Self
source: unknown
absolute_source: unknown
libm::sqrtf._1: f32
std::io::_print._1: std::fmt::Arguments<'_>
std::iter::IntoIterator::into_iter._1: Self
std::iter::Iterator::next._1: &mut Self
source: unknown
absolute_source: unknown
core::fmt::rt::Argument::<'_>::new_debug._1: &T
source: unknown
absolute_source: unknown
std::fmt::Arguments::<'a>::new._1: &'a [u8; N]
source: unknown
absolute_source: unknown
std::fmt::Arguments::<'a>::new._2: &'a [core::fmt::rt::Argument<'a>; M]
source: unknown
absolute_source: unknown
Outputs:
test_startracker._0
tests::startracker::startracker._0

h313

Good work! We should iterate a bit on our DFS and cycle detection approach.

h313 · 2026-06-05T15:04:17Z

+ }
+
+ while let Some(caller) = worklist.pop() {
+ if !visited.insert(caller) {


What happens if the same function gets called by two different functions? Would it make sense to process each function call individually?

h313 · 2026-06-05T15:07:57Z

+ continue;
+ };
+
+ for callsite in &caller_summary.callsites {


What happens if we have call the same function multiple times? Would it make sense to record each one as separate function calls in our summary, or should we have the summary output just once for each function?

ebepho · 2026-06-04T15:48:21Z

Changed the pass to an initial interprocedural report. It now starts from a protected root, walks the reachable call tree, separates local vs external calls, and prints the formal inputs for functions reached inside the protected region.

The implementation is organized as two stages:

Local MIR summary pass: records each function’s formal args, callsites, return source, and simple local provenance.
Interprocedural propagation/report pass: starts from #[rad_protected], walks reachable calls, binds caller actuals to callee, and reports sources/absolute sources.

Tested on test_startracker():

=== Protected Function Analysis ===
Protected root: test_startracker
Reached functions:
- test_startracker
- tests::startracker::startracker
- std::iter::IntoIterator::into_iter (external)
- std::iter::Iterator::next (external)
- rand::random (external)
- core::fmt::rt::Argument::<'_>::new_debug (external)
- std::fmt::Arguments::<'a>::new (external)
- std::io::_print (external)
- libm::sqrtf (external)
Call tree:
test_startracker
├── tests::startracker::startracker
├── std::iter::IntoIterator::into_iter (external)
├── std::iter::Iterator::next (external)
└── libm::sqrtf (external)
├── std::io::_print (external)
├── std::iter::IntoIterator::into_iter (external)
├── std::iter::Iterator::next (external)
├── core::fmt::rt::Argument::<'_>::new_debug (external)
├── std::fmt::Arguments::<'a>::new (external)
└── rand::random (external)
Inputs:
tests::startracker::startracker._1: &[f32; 4]
source: test_startracker._23
absolute_source: test_startracker._23
tests::startracker::startracker._2: &[f32; 4]
source: test_startracker._25
absolute_source: test_startracker._25
tests::startracker::startracker._3: &mut [f32; 6]
source: test_startracker._27
absolute_source: test_startracker._27
std::iter::IntoIterator::into_iter._1: Self
std::iter::Iterator::next._1: &mut Self
source: unknown
absolute_source: unknown
libm::sqrtf._1: f32
std::io::_print._1: std::fmt::Arguments<'_>
std::iter::IntoIterator::into_iter._1: Self
std::iter::Iterator::next._1: &mut Self
source: unknown
absolute_source: unknown
core::fmt::rt::Argument::<'_>::new_debug._1: &T
source: unknown
absolute_source: unknown
std::fmt::Arguments::<'a>::new._1: &'a [u8; N]
source: unknown
absolute_source: unknown
std::fmt::Arguments::<'a>::new._2: &'a [core::fmt::rt::Argument<'a>; M]
source: unknown
absolute_source: unknown
Outputs:
test_startracker._0
tests::startracker::startracker._0

h313

Good work! We should iterate a bit on our DFS and cycle detection approach.

h313 · 2026-06-05T15:04:17Z

+ }
+
+ while let Some(caller) = worklist.pop() {
+ if !visited.insert(caller) {


What happens if the same function gets called by two different functions? Would it make sense to process each function call individually?

h313 · 2026-06-05T15:07:57Z

+ continue;
+ };
+
+ for callsite in &caller_summary.callsites {


What happens if we have call the same function multiple times? Would it make sense to record each one as separate function calls in our summary, or should we have the summary output just once for each function?

ebepho · 2026-06-04T15:48:21Z

Changed the pass to an initial interprocedural report. It now starts from a protected root, walks the reachable call tree, separates local vs external calls, and prints the formal inputs for functions reached inside the protected region.

The implementation is organized as two stages:

Local MIR summary pass: records each function’s formal args, callsites, return source, and simple local provenance.
Interprocedural propagation/report pass: starts from #[rad_protected], walks reachable calls, binds caller actuals to callee, and reports sources/absolute sources.

Tested on test_startracker():

=== Protected Function Analysis ===
Protected root: test_startracker
Reached functions:
- test_startracker
- tests::startracker::startracker
- std::iter::IntoIterator::into_iter (external)
- std::iter::Iterator::next (external)
- rand::random (external)
- core::fmt::rt::Argument::<'_>::new_debug (external)
- std::fmt::Arguments::<'a>::new (external)
- std::io::_print (external)
- libm::sqrtf (external)
Call tree:
test_startracker
├── tests::startracker::startracker
├── std::iter::IntoIterator::into_iter (external)
├── std::iter::Iterator::next (external)
└── libm::sqrtf (external)
├── std::io::_print (external)
├── std::iter::IntoIterator::into_iter (external)
├── std::iter::Iterator::next (external)
├── core::fmt::rt::Argument::<'_>::new_debug (external)
├── std::fmt::Arguments::<'a>::new (external)
└── rand::random (external)
Inputs:
tests::startracker::startracker._1: &[f32; 4]
source: test_startracker._23
absolute_source: test_startracker._23
tests::startracker::startracker._2: &[f32; 4]
source: test_startracker._25
absolute_source: test_startracker._25
tests::startracker::startracker._3: &mut [f32; 6]
source: test_startracker._27
absolute_source: test_startracker._27
std::iter::IntoIterator::into_iter._1: Self
std::iter::Iterator::next._1: &mut Self
source: unknown
absolute_source: unknown
libm::sqrtf._1: f32
std::io::_print._1: std::fmt::Arguments<'_>
std::iter::IntoIterator::into_iter._1: Self
std::iter::Iterator::next._1: &mut Self
source: unknown
absolute_source: unknown
core::fmt::rt::Argument::<'_>::new_debug._1: &T
source: unknown
absolute_source: unknown
std::fmt::Arguments::<'a>::new._1: &'a [u8; N]
source: unknown
absolute_source: unknown
std::fmt::Arguments::<'a>::new._2: &'a [core::fmt::rt::Argument<'a>; M]
source: unknown
absolute_source: unknown
Outputs:
test_startracker._0
tests::startracker::startracker._0

h313

Good work! We should iterate a bit on our DFS and cycle detection approach.

h313 · 2026-06-05T15:04:17Z

+ }
+
+ while let Some(caller) = worklist.pop() {
+ if !visited.insert(caller) {


What happens if the same function gets called by two different functions? Would it make sense to process each function call individually?

h313 · 2026-06-05T15:07:57Z

+ continue;
+ };
+
+ for callsite in &caller_summary.callsites {


What happens if we have call the same function multiple times? Would it make sense to record each one as separate function calls in our summary, or should we have the summary output just once for each function?

ebepho · 2026-06-04T15:48:21Z

Changed the pass to an initial interprocedural report. It now starts from a protected root, walks the reachable call tree, separates local vs external calls, and prints the formal inputs for functions reached inside the protected region.

The implementation is organized as two stages:

Local MIR summary pass: records each function’s formal args, callsites, return source, and simple local provenance.
Interprocedural propagation/report pass: starts from #[rad_protected], walks reachable calls, binds caller actuals to callee, and reports sources/absolute sources.

Tested on test_startracker():

=== Protected Function Analysis ===
Protected root: test_startracker
Reached functions:
- test_startracker
- tests::startracker::startracker
- std::iter::IntoIterator::into_iter (external)
- std::iter::Iterator::next (external)
- rand::random (external)
- core::fmt::rt::Argument::<'_>::new_debug (external)
- std::fmt::Arguments::<'a>::new (external)
- std::io::_print (external)
- libm::sqrtf (external)
Call tree:
test_startracker
├── tests::startracker::startracker
├── std::iter::IntoIterator::into_iter (external)
├── std::iter::Iterator::next (external)
└── libm::sqrtf (external)
├── std::io::_print (external)
├── std::iter::IntoIterator::into_iter (external)
├── std::iter::Iterator::next (external)
├── core::fmt::rt::Argument::<'_>::new_debug (external)
├── std::fmt::Arguments::<'a>::new (external)
└── rand::random (external)
Inputs:
tests::startracker::startracker._1: &[f32; 4]
source: test_startracker._23
absolute_source: test_startracker._23
tests::startracker::startracker._2: &[f32; 4]
source: test_startracker._25
absolute_source: test_startracker._25
tests::startracker::startracker._3: &mut [f32; 6]
source: test_startracker._27
absolute_source: test_startracker._27
std::iter::IntoIterator::into_iter._1: Self
std::iter::Iterator::next._1: &mut Self
source: unknown
absolute_source: unknown
libm::sqrtf._1: f32
std::io::_print._1: std::fmt::Arguments<'_>
std::iter::IntoIterator::into_iter._1: Self
std::iter::Iterator::next._1: &mut Self
source: unknown
absolute_source: unknown
core::fmt::rt::Argument::<'_>::new_debug._1: &T
source: unknown
absolute_source: unknown
std::fmt::Arguments::<'a>::new._1: &'a [u8; N]
source: unknown
absolute_source: unknown
std::fmt::Arguments::<'a>::new._2: &'a [core::fmt::rt::Argument<'a>; M]
source: unknown
absolute_source: unknown
Outputs:
test_startracker._0
tests::startracker::startracker._0

h313

Good work! We should iterate a bit on our DFS and cycle detection approach.

h313 · 2026-06-05T15:04:17Z

+ }
+
+ while let Some(caller) = worklist.pop() {
+ if !visited.insert(caller) {


What happens if the same function gets called by two different functions? Would it make sense to process each function call individually?

h313 · 2026-06-05T15:07:57Z

+ continue;
+ };
+
+ for callsite in &caller_summary.callsites {


What happens if we have call the same function multiple times? Would it make sense to record each one as separate function calls in our summary, or should we have the summary output just once for each function?

ebepho · 2026-06-04T15:48:21Z

Changed the pass to an initial interprocedural report. It now starts from a protected root, walks the reachable call tree, separates local vs external calls, and prints the formal inputs for functions reached inside the protected region.

The implementation is organized as two stages:

Local MIR summary pass: records each function’s formal args, callsites, return source, and simple local provenance.
Interprocedural propagation/report pass: starts from #[rad_protected], walks reachable calls, binds caller actuals to callee, and reports sources/absolute sources.

Tested on test_startracker():

=== Protected Function Analysis ===
Protected root: test_startracker
Reached functions:
- test_startracker
- tests::startracker::startracker
- std::iter::IntoIterator::into_iter (external)
- std::iter::Iterator::next (external)
- rand::random (external)
- core::fmt::rt::Argument::<'_>::new_debug (external)
- std::fmt::Arguments::<'a>::new (external)
- std::io::_print (external)
- libm::sqrtf (external)
Call tree:
test_startracker
├── tests::startracker::startracker
├── std::iter::IntoIterator::into_iter (external)
├── std::iter::Iterator::next (external)
└── libm::sqrtf (external)
├── std::io::_print (external)
├── std::iter::IntoIterator::into_iter (external)
├── std::iter::Iterator::next (external)
├── core::fmt::rt::Argument::<'_>::new_debug (external)
├── std::fmt::Arguments::<'a>::new (external)
└── rand::random (external)
Inputs:
tests::startracker::startracker._1: &[f32; 4]
source: test_startracker._23
absolute_source: test_startracker._23
tests::startracker::startracker._2: &[f32; 4]
source: test_startracker._25
absolute_source: test_startracker._25
tests::startracker::startracker._3: &mut [f32; 6]
source: test_startracker._27
absolute_source: test_startracker._27
std::iter::IntoIterator::into_iter._1: Self
std::iter::Iterator::next._1: &mut Self
source: unknown
absolute_source: unknown
libm::sqrtf._1: f32
std::io::_print._1: std::fmt::Arguments<'_>
std::iter::IntoIterator::into_iter._1: Self
std::iter::Iterator::next._1: &mut Self
source: unknown
absolute_source: unknown
core::fmt::rt::Argument::<'_>::new_debug._1: &T
source: unknown
absolute_source: unknown
std::fmt::Arguments::<'a>::new._1: &'a [u8; N]
source: unknown
absolute_source: unknown
std::fmt::Arguments::<'a>::new._2: &'a [core::fmt::rt::Argument<'a>; M]
source: unknown
absolute_source: unknown
Outputs:
test_startracker._0
tests::startracker::startracker._0

h313

Good work! We should iterate a bit on our DFS and cycle detection approach.

h313 · 2026-06-05T15:04:17Z

+ }
+
+ while let Some(caller) = worklist.pop() {
+ if !visited.insert(caller) {


What happens if the same function gets called by two different functions? Would it make sense to process each function call individually?

h313 · 2026-06-05T15:07:57Z

+ continue;
+ };
+
+ for callsite in &caller_summary.callsites {


What happens if we have call the same function multiple times? Would it make sense to record each one as separate function calls in our summary, or should we have the summary output just once for each function?

ebepho · 2026-06-04T15:48:21Z

Changed the pass to an initial interprocedural report. It now starts from a protected root, walks the reachable call tree, separates local vs external calls, and prints the formal inputs for functions reached inside the protected region.

The implementation is organized as two stages:

Local MIR summary pass: records each function’s formal args, callsites, return source, and simple local provenance.
Interprocedural propagation/report pass: starts from #[rad_protected], walks reachable calls, binds caller actuals to callee, and reports sources/absolute sources.

Tested on test_startracker():

=== Protected Function Analysis ===
Protected root: test_startracker
Reached functions:
- test_startracker
- tests::startracker::startracker
- std::iter::IntoIterator::into_iter (external)
- std::iter::Iterator::next (external)
- rand::random (external)
- core::fmt::rt::Argument::<'_>::new_debug (external)
- std::fmt::Arguments::<'a>::new (external)
- std::io::_print (external)
- libm::sqrtf (external)
Call tree:
test_startracker
├── tests::startracker::startracker
├── std::iter::IntoIterator::into_iter (external)
├── std::iter::Iterator::next (external)
└── libm::sqrtf (external)
├── std::io::_print (external)
├── std::iter::IntoIterator::into_iter (external)
├── std::iter::Iterator::next (external)
├── core::fmt::rt::Argument::<'_>::new_debug (external)
├── std::fmt::Arguments::<'a>::new (external)
└── rand::random (external)
Inputs:
tests::startracker::startracker._1: &[f32; 4]
source: test_startracker._23
absolute_source: test_startracker._23
tests::startracker::startracker._2: &[f32; 4]
source: test_startracker._25
absolute_source: test_startracker._25
tests::startracker::startracker._3: &mut [f32; 6]
source: test_startracker._27
absolute_source: test_startracker._27
std::iter::IntoIterator::into_iter._1: Self
std::iter::Iterator::next._1: &mut Self
source: unknown
absolute_source: unknown
libm::sqrtf._1: f32
std::io::_print._1: std::fmt::Arguments<'_>
std::iter::IntoIterator::into_iter._1: Self
std::iter::Iterator::next._1: &mut Self
source: unknown
absolute_source: unknown
core::fmt::rt::Argument::<'_>::new_debug._1: &T
source: unknown
absolute_source: unknown
std::fmt::Arguments::<'a>::new._1: &'a [u8; N]
source: unknown
absolute_source: unknown
std::fmt::Arguments::<'a>::new._2: &'a [core::fmt::rt::Argument<'a>; M]
source: unknown
absolute_source: unknown
Outputs:
test_startracker._0
tests::startracker::startracker._0

h313

Good work! We should iterate a bit on our DFS and cycle detection approach.

h313 · 2026-06-05T15:04:17Z

+ }
+
+ while let Some(caller) = worklist.pop() {
+ if !visited.insert(caller) {


What happens if the same function gets called by two different functions? Would it make sense to process each function call individually?

h313 · 2026-06-05T15:07:57Z

+ continue;
+ };
+
+ for callsite in &caller_summary.callsites {


What happens if we have call the same function multiple times? Would it make sense to record each one as separate function calls in our summary, or should we have the summary output just once for each function?

v1
4a47dd6

ebepho changed the title ~~Inter-procedural Analysis~~Inter-Procedural AnalysisJun 4, 2026

h313 requested changes Jun 5, 2026
View reviewed changes

ebepho added 2 commits June 12, 2026 06:55

clean up
bce7690

cleanup
90d8f4a

v1
4a47dd6

ebepho changed the title ~~Inter-procedural Analysis~~Inter-Procedural AnalysisJun 4, 2026

h313 requested changes Jun 5, 2026
View reviewed changes

ebepho added 2 commits June 12, 2026 06:55

clean up
bce7690

cleanup
90d8f4a

v1
4a47dd6

ebepho changed the title ~~Inter-procedural Analysis~~Inter-Procedural AnalysisJun 4, 2026

h313 requested changes Jun 5, 2026
View reviewed changes

ebepho added 2 commits June 12, 2026 06:55

clean up
bce7690

cleanup
90d8f4a

v1
4a47dd6

ebepho changed the title ~~Inter-procedural Analysis~~Inter-Procedural AnalysisJun 4, 2026

h313 requested changes Jun 5, 2026
View reviewed changes

ebepho added 2 commits June 12, 2026 06:55

clean up
bce7690

cleanup
90d8f4a

v1
4a47dd6

ebepho changed the title ~~Inter-procedural Analysis~~Inter-Procedural AnalysisJun 4, 2026

h313 requested changes Jun 5, 2026
View reviewed changes

ebepho added 2 commits June 12, 2026 06:55

clean up
bce7690

cleanup
90d8f4a

v1
4a47dd6

ebepho changed the title ~~Inter-procedural Analysis~~Inter-Procedural AnalysisJun 4, 2026

h313 requested changes Jun 5, 2026
View reviewed changes

ebepho added 2 commits June 12, 2026 06:55

clean up
bce7690

cleanup
90d8f4a

v1
4a47dd6

ebepho changed the title ~~Inter-procedural Analysis~~Inter-Procedural AnalysisJun 4, 2026

h313 requested changes Jun 5, 2026
View reviewed changes

ebepho added 2 commits June 12, 2026 06:55

clean up
bce7690

cleanup
90d8f4a

v1
4a47dd6

ebepho changed the title ~~Inter-procedural Analysis~~Inter-Procedural AnalysisJun 4, 2026

h313 requested changes Jun 5, 2026
View reviewed changes

ebepho added 2 commits June 12, 2026 06:55

clean up
bce7690

cleanup
90d8f4a

Uh oh!

Conversation

ebepho commented Jun 4, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

h313 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

ebepho commented Jun 4, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

h313 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

ebepho commented Jun 4, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

h313 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

ebepho commented Jun 4, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

h313 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

ebepho commented Jun 4, 2026•
edited
Loading

ebepho commented Jun 4, 2026•
edited
Loading

ebepho commented Jun 4, 2026•
edited
Loading

ebepho commented Jun 4, 2026•
edited
Loading

ebepho commented Jun 4, 2026•
edited
Loading

ebepho commented Jun 4, 2026•
edited
Loading