NightOwl888 commented on issue #1098: URL: https://github.com/apache/lucenenet/issues/1098#issuecomment-2585607178
Thanks. I wasn't aware that `StackTraceHelper` was public and we definitely shouldn't be encouraging users to write tests that check the stack trace, so let's mark it internal. Of course, if we can come up with an alternative to checking the stack trace for places where Lucene used it, suggestions are welcome. Sometimes the method we are looking for is several levels up the stack from where we are looking for it. Using the `nameof()` operator assumes that we know the specific method that is supposed to be calling us, but generally we don't. We only have the strings that we got from Lucene. We could take a best guess, but that would be misleading if we guess wrong. Of course, now that we have running tests, we can probably pause or do logging and work it out in the more trivial cases, but it is going to take more time to do than suppressing the warning. Since we have dropped support for .NET Standard 1.x which had a lot of code to work around the lack of stack trace support, maybe we should eliminate the `StackTraceHelper` and put the translated code inline. It would improve performance in some cases, for example in `TestConcurrentMergeScheduler`, Lucene has:  Putting the stack trace code inline would allow us to check the stack for both strings at once and exit as soon as both are found. But as you can see, these are some really common method names. Without knowing specifically which one Lucene is scanning for, we must put `[MethodImpl(MethodImplOptions.NoInlining)]` on all `Flush` methods to ensure the test will pass. I think in this case we looked up which specific `Dispose()` method required no inlining, since it would be impractical and cause performance issues if we did that to all of them. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@lucenenet.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
