Skip to content
This repository has been archived by the owner on Dec 13, 2018. It is now read-only.

Hack: Provide better information on error when related to different line #1

Closed
SiebelsTim opened this issue May 24, 2015 · 3 comments
Closed

Hack: Provide better information on error when related to different line #1

SiebelsTim opened this issue May 24, 2015 · 3 comments

Comments

@SiebelsTim
Copy link

You could often receive an error like this:

... This is an int
... It is incompatible with object of type...

Nuclide however shows only the This is an int error on the line where it's an int. You'd have to start hh_client to find the erroring line.

Example with error with different implementations in inheritance:
The real error is in a child class, which can be confusing.
nucl3
@SiebelsTim SiebelsTim changed the title Provide better information on error when related to different line Hack: Provide better information on error when related to different line May 24, 2015
@mostafaeweda
Copy link
Contributor

I could reproduce that and will work on a fix where you would see the error in the caller (part 1) and could navigate to the method definition from the tooltip (part 2).

@steelbrain steelbrain mentioned this issue May 27, 2015
Closed
@mostafaeweda
Copy link
Contributor

part one is now fixed with: cb35f22
part two will come later with the usage of linter-plus

jgebhardt pushed a commit that referenced this issue Aug 31, 2015
@rameshvarun
Service Framework 3.0 Diff #1 - Parser
9e1b792
jgebhardt pushed a commit that referenced this issue Aug 31, 2015
@rameshvarun
Service Framework Diff #1.5 - Validation Script
fbbc130
@nrze nrze mentioned this issue Sep 6, 2015
Closed
@mostafaeweda
Copy link
Contributor

that was fixed by the introduction of traces with the new diagnostics framework

ghost pushed a commit that referenced this issue Apr 22, 2016
Use faster setText when replacing entire buffer contents
539c6d7 
Summary:`setText` is 3-4x faster than `setTextViaDiff`. Using it when replacing
the entire contents of the buffer makes clicking through files in the
diff-view tree show the file up to 100ms faster.

**Test run #1**

setText, 39.4ms:
{F60653266}

setTextViaDiff, 170.5ms:
{F60653267}

**Test run #2**

setText, 68.4ms:
{F60653269}

setTextViaDiff, 171.8ms:
{F60653270}

Reviewed By: mostafaeweda

Differential Revision: D3203887

fb-gh-sync-id: 7d78e07373d688654f6f6f723f30013ffe9e06fd
fbshipit-source-id: 7d78e07373d688654f6f6f723f30013ffe9e06fd
ghost pushed a commit that referenced this issue Jun 23, 2016
@johnislarry
Console diff #1 -- Support evaluation in non-break state
5f29725 
Summary: The console window only supported evaluation when the debugger was in paused mode, and now it supports evaluation via the dummy connection.

Reviewed By: yinghuitan

Differential Revision: D3406859

fbshipit-source-id: 6eda0dbc3ed621a9fd95055a62a487acc3e0da50
ghost pushed a commit that referenced this issue Jul 28, 2016
@johnislarry
breakpoint notifications #1 -- Servicify the notifications package
e3ebd01 
Summary:
We will consume this function in the debugger, and want to take advantage of the
setting-awareness/focusing/styling done in the notifications package.

Reviewed By: jgebhardt

Differential Revision: D3625306

fbshipit-source-id: a0c12e908a4ada0a2ccf7c5381bd75e15d3a67f0
ghost pushed a commit that referenced this issue Aug 9, 2016
@zertosh
Delay quick-open panel creation until used
f3a446d 
Summary:
This diff reduces Nuclide's startup time by ~80ms. Most of this expense is the result of two forced layouts caused by quick-open: (1) measuring the document's height for the scrollable area `max-height` calculation, and (2) adding the panel to the DOM.

To fix #1, instead of setting the height in javascript of the scrollable area, it's set using CSS. The `max-height` is now `calc(100vh - GAPpx)`. Not only is this less taxing on Atom, but the modal now shrinks smoothly as you resize.

To fix #2, moved the panel creation code into the Activation class' render. Since that function got kinda big, I trimmed some of the unnecessary bits - like most of the styling on the modal parent.

Reviewed By: jgebhardt

Differential Revision: D3683543

fbshipit-source-id: 3b09bdcdd7f3aabb4e9162d68fbf6cdc44434f40
ghost pushed a commit that referenced this issue Aug 23, 2016
@johnislarry
Debugger Eval #1 -- Prevent caching of evaluations
c92045f 
Summary:
This diff extends the evaluation logic in the Bridge so that we use unique id's to identify evaluation requests/responses.  Because of this, the Bridge won't do any extra caching of evaluation requests, which is good for use cases like evaluating functions with bp's in their body -- where the result won't come back until at least one debugger pause event is emitted.

I know that adding this logic into the Bridge is not great -- so the next diff in the stack D3699243 refactors all of this logic out of the Bridge.

Reviewed By: yinghuitan

Differential Revision: D3688065

fbshipit-source-id: 0aa37358651b9e3f615288b0ed933fd9018efda0
facebook-github-bot pushed a commit that referenced this issue Oct 7, 2016
@johnislarry
iwdp debugger #1 -- introduce end to end iwdp debugger
4de9360 
Reviewed By: jgebhardt

Differential Revision: D3963634

fbshipit-source-id: 7cbfff8e4f24ec39270cef080c458cc125517372
facebook-github-bot pushed a commit that referenced this issue Dec 6, 2016
@johnislarry
Relax ordering restriction for eval ids
e0725e7 
Summary:
Here is a correct scenario in which evaluation requests can be completed "out of order":

1. eval request #1 is sent, push #1 onto stack
2. eval request #2 is sent, push #2 onto stack
3. response for #1 comes back from HHVM, pop #2 off stack
4. #1 != #2 so the invariant is triggered

So we can be more lax about the expected order that we receive responses.  In general, there's no reason to impose any restrictions on the ordering in which requests and responses happen, so let's just use a set.

Changelog: Fix for PHP debugger evaluation crashes.

Reviewed By: yinghuitan

Differential Revision: D4282772

fbshipit-source-id: 7d6169fa660d489b06b1a28e07140fa11a5464e4
facebook-github-bot pushed a commit that referenced this issue Feb 3, 2017
@johnislarry @facebook-github-bot
disposal #1: Introduce ENDED mode for debugger connections
1978f00 
Summary:
Currently we have no way of handling "bottom up" disposals, for example, if a js script exits on it's
own, we still keep the socket connection around.  ENDED connections are connections to JSContexts that have
had their websocket closed.

Differential Revision: D4505657

fbshipit-source-id: 9b6265950f9690849d020ffa7acf875efc5d3c23
facebook-github-bot pushed a commit that referenced this issue Sep 19, 2018
@facebook-github-bot
Give OCaml threads a more professional name in the debugger.
4b95a36 
Summary: `"Please, this is OCaml"` is unnecessarily dismissive and unprofessional.  Rename it to "Thread #1."

Reviewed By: arxanas

Differential Revision: D9928275

fbshipit-source-id: 1752e548fc3e2029d87f8dce03dce47dbf536009
facebook-github-bot pushed a commit that referenced this issue Oct 11, 2018
@evangrayk @facebook-github-bot
Compact commit header
5eae3a6 
Summary:
The previous header for each commit in interactive split was quite large and bulky, taking away valuable vertical space for code. This change slims it down so the commit number is on the same line as the title box and fold/unfold buttons.

EDIT:
I've updated it now, so that it also shows "1/n" instead of "Commit #1" which is a lot more terse. I moved the input box to the left, and removed the background color. "Leave Changes Uncommitted" is now on its own line (which is fine since nothing wraps)

Reviewed By: aadisriram

Differential Revision: D10225822

fbshipit-source-id: 2197a039510d983b20e7740de057985ce3ad3256
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mostafaeweda @SiebelsTim