[Lldb-commits] [lldb] r367066 - [Docs] Remove reproducers from the project page.

[Jonas Devlieghere via lldb-commits]

Author: jdevlieghere
Date: Thu Jul 25 15:22:43 2019
New Revision: 367066

URL: http://llvm.org/viewvc/llvm-project?rev=367066&view=rev
Log:
[Docs] Remove reproducers from the project page.

Jim pointed out that this was still open on the website.

Modified:
    lldb/trunk/docs/status/projects.rst

Modified: lldb/trunk/docs/status/projects.rst
URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/status/projects.rst?rev=367066&r1=367065&r2=367066&view=diff
==============================================================================
--- lldb/trunk/docs/status/projects.rst (original)
+++ lldb/trunk/docs/status/projects.rst Thu Jul 25 15:22:43 2019
@@ -291,21 +291,6 @@ state at StopPoint 0, StopPoint 1, etc.
 reactions to complex threading problems & the like, and also for simulating
 hard-to-test environments (like bare board debugging).
 
-A Bug-Trapper infrastructure
-----------------------------
-
-We very often have bugs that can't be reproduced locally. So having a
-bug-report-trapper that can gather enough information from the surroundings of
-a bug so that we can replay the session locally would be a big help tracking
-down issues in this situation. This is tricky because you can't necessarily
-require folks to leak information about their code in order to file bug
-reports. So not only will you have to figure out what state to gather, you're
-also going to have to anonymize it somehow. But we very often have bugs from
-people that can't reduce the problem to a simple test case and can't give us
-our code, and we often just can't help them as things stand now. Note that
-adding the ProcessMock would be a good first stage towards this, since you
-could make a ProcessMock creator/serializer from the current lldb state.
-
 Expression parser needs syntax for "{symbol,type} A in CU B.cpp"
 ----------------------------------------------------------------
 
@@ -393,21 +378,21 @@ Teach lldb to predict exception propagat
 -------------------------------------------------------------
 
 There are a bunch of places in lldb where we need to know at the point where an
-exception is thrown, what frame will catch the exception.  
+exception is thrown, what frame will catch the exception.
 
-For instance, if an expression throws an exception, we need to know whether the 
-exception will be caught in the course of the expression evaluation.  If so it 
-would be safe to let the expression continue.  But since we would destroy the 
-state of the thread if we let the exception escape the expression, we currently 
+For instance, if an expression throws an exception, we need to know whether the
+exception will be caught in the course of the expression evaluation.  If so it
+would be safe to let the expression continue.  But since we would destroy the
+state of the thread if we let the exception escape the expression, we currently
 stop the expression evaluation if we see a throw.  If we knew where it would be
 caught we could distinguish these two cases.
 
-Similarly, when you step over a call that throws, you want to stop at the throw 
+Similarly, when you step over a call that throws, you want to stop at the throw
 point if you know the exception will unwind past the frame you were stepping in,
 but it would annoying to have the step abort every time an exception was thrown.
 If we could predict the catching frame, we could do this right.
 
-And of course, this would be a useful piece of information to display when stopped 
+And of course, this would be a useful piece of information to display when stopped
 at a throw point.
 
 Add predicates to the nodes of settings