| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes the bug and implements the feature request of #3000.
1. If `Module` is a real module name and `identifier` a name of a
top-level function in `Module` then `:break Module.identifer` works
also for an `identifier` that is out of scope.
2. Extend the syntax for `:break identifier` to:
:break [ModQual.]topLevelIdent[.nestedIdent]...[.nestedIdent]
`ModQual` is optional and is either the effective name of a module or
the local alias of a qualified import statement.
`topLevelIdent` is the name of a top level function in the module
referenced by `ModQual`.
`nestedIdent` is optional and the name of a function nested in a let or
where clause inside the previously mentioned function `nestedIdent` or
`topLevelIdent`.
If `ModQual` is a module name, then `topLevelIdent` can be any top level
identifier in this module. If `ModQual` is missing or a local alias of a
qualified import, then `topLevelIdent` must be in scope.
Breakpoints can be set on arbitrarily deeply nested functions, but the
whole chain of nested function names must be specified.
3. To support the new functionality rewrite the code to tab complete `:break`.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously it was a SrcSpan, which can be an UnhelpulSrcSpan,
but actually for TcLclEnv and CtLoc we always know it is
a real source location, and it's good to make the types
reflect that fact.
There is a continuing slight awkwardness (not new with this
patch) about what "file name" to use for GHCi code. Current
we say "<interactive>" which seems just about OK.
|
| |
|
|
|
| |
This fixes Trac #9881, and gives more helpful output in the case of ambiguity.
Certainly more helpful than the positively-misleading error we get right now.
|
| |
|
|
|
|
|
| |
This matches GCC's choice of Unicode quotation marks (i.e. U+2018 and U+2019)
and therefore looks more familiar on the console. This addresses #2507.
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
|
| | |
|
| |
|
