Commit 8c9f6e6
committed
fix: When deciding to alias an object or not during inspection, consider module paths to be equivalent even with arbitrary private components
When deciding whether an object should be aliased during dynamic analysis, we previously said "no" only if the parent module path and the child module path were equal after removing any leading underscores. In short, `_a` is equal to `a`, and `a.b` is equal to `_a.b`.
But in some cases (see mentioned issue), path components other than the first have leading underscores or not. For example: `a.b` and `a._b`. These cases where not supported, and would result in objects being aliased instead of inspected in-place, later causing alias resolution issues (cyclic aliases, pointing at themselves).
Now we decide that paths are equivalent if all their components stripped from leading underscores are equal. It means that cases like `a._b.c` vs. `a.b._c` are supported, and an object analyzed in one of them but declared in the other will be inspected in-place and not aliased. Even though this specific case is weird (like many other possible cases), we suppose that users know what they are doing with their module layout / public-private API.
Issue-296: #2961 parent 6e17def commit 8c9f6e6
1 file changed
Lines changed: 9 additions & 5 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
17 | 17 | | |
18 | 18 | | |
19 | 19 | | |
20 | | - | |
21 | 20 | | |
22 | 21 | | |
23 | 22 | | |
| 23 | + | |
| 24 | + | |
| 25 | + | |
| 26 | + | |
| 27 | + | |
24 | 28 | | |
25 | 29 | | |
26 | 30 | | |
| |||
253 | 257 | | |
254 | 258 | | |
255 | 259 | | |
256 | | - | |
257 | | - | |
258 | | - | |
259 | | - | |
| 260 | + | |
| 261 | + | |
| 262 | + | |
| 263 | + | |
260 | 264 | | |
261 | 265 | | |
262 | 266 | | |
| |||
0 commit comments