IDxcIncludeHandler::LoadSource() the pFilename path get messed up when multi-level included from different search paths

I'm tracking the header file dependencies. So I use a custom IDxcIncludeHandler to record each file loaded
But when multiple header include each other, the incoming pFilename is incorrect

For example
I have a folder tree

D:
--include (folder)
---- A.h
---- B.h
---- A (folder)
------ A.h
---- B (folder)
------ B.h
--src (folder)
---- A (folder)
------ A.hlsl

include/A.h
#error

include/B.h
#error

include/A/A.h
#include "B/B.h"

include/B/B.h
//the code I need

src/A/A.hlsl
#include "A/A.h"

I passed in include search path D:/include

D:/src/A/A.hlsl was passed in as pSourceName as the BuildArguments

1. When compiling A.hlsl and redirect #include "A/A.h", the custom IDxIncludeHandler::LoadSource get called, the pFilename is "D:/src/A/A/A.h"
2. When compiling A.h and redirect #include "B/B.h", the pFilename is "D:/src/A/A/B/B.h"

In case 1, I think pFilename is combined with source file location with the included path D:/src/A + A/A.h
I can correct it by comparing pFilename to the source file path D:/src/A/A.hlsl, and get the relative path A/A.h
Then I can use the include search path to find the correct file location D:/include + A/A.h

But in case 2, pFilename get one more level of relative path A included, it is D:/src/A + A + B/B.h
The relative path to the source file will be A/B/B.h, which is incorrect. But I also can't just search B.h aimlessly, because I may hit the wrong file

With the DefaultDxcIncludeHandler, the compiling will be passed. So I think the internal logic push/pop the local relative path during the include handling. But the custom IDxcIncludeHandler lack such information and cannot track the relative include tree

So, either only put what #include followed in pFilename just like what D3DCompile do, or provide us more info about the include tree so we can handle it correctly

Start by reproducing the nested include tree with a custom IDxcIncludeHandler and compare its LoadSource pFilename values with the DefaultDxcIncludeHandler. Read the include-handling implementation and interface behavior, then verify that nested headers from different search paths can be resolved without losing the include context.