@ateoi Thanks for fixing this!

Great to see a fix for this.

You might want to open a bug in the dotnet/docs repo to update this text for 2.1:

If the exception is thrown, and later rethrown, in the same method, the stack trace only contains the location where the exception was rethrown and does not include the location where the exception was originally thrown.

Also, would you be willing to open a PR in the corefx repo to add a test? I am not certain the best place, I don't see tests specifically for what is in Exception.StackTrace. Some possible places are

src\System.Runtime\tests\System\Runtime\ExceptionServices\ExceptionDispatchInfoTests.netcoreapp.cs
src\System.Runtime.Extensions\tests\System\Environment.StackTrace.cs
src\System.Diagnostics.StackTrace\tests\StackTraceTests.cs
src\System.Runtime\tests\System\ExceptionTests.cs
A naive test could do something like

        static int expectedThrowLine;

       [Fact]
        static void ThrowStatementDoesNotResetExceptionStackLine()
        {
            try
            {
                DoStuff();
            }
            catch (Exception ex)
            {
                int reportedThrowLine = Convert.ToInt32(Regex.Match(ex.StackTrace, @".*DoStuff[^\n]*line (\d+)", RegexOptions.Multiline).Groups[1].Value);
                Assert.Equals(expectedThrowLine, reportedThrowLine);
            }

        }

        private static void DoStuff()
        {
            try
            {
                expectedThrowLine = 1 + Convert.ToInt32(Regex.Match(Environment.StackTrace, @".*DoStuff[^\n]*line (\d+)", RegexOptions.Multiline).Groups[1].Value);
                throw new Exception("Boom!");
            }
            catch (Exception)
            {
                throw;
            }
        }

Our tests for ExceptionDispatchInfo (all in ExceptionDispatchInfoTests.netcoreapp.cs) probably ought to do some similar line number verification (example). Not your job, of course.

Ok, I can open a bug for the doc and submit a PR to add a test.

@jkotas any other feedback?

Oop, we generally wait for the test PR to be up before merging the implementation PR.

@jkotas any other feedback?

Looks fine to me.

we generally wait for the test PR to be up before merging the implementation PR.

As far as I know, we have no automated tests for the stacktraces, and we have merged number of tweaks of the stacktraces without them (e.g. #14655). It would be a bit unfair to block this one on tests. I agree that we should add tests for this though.

OK