This makes (:type (Number -> Integer)) produce
(Number -> Integer) instead of expanding at the first name.
Combined with expansion cues, this makes it easier for users
to expand the relevant parts of types.
This tells the user that more type aliases are
available for expansion. For example, (Listof Number)
has the alias Number still unexpanded into the union
that it represents.
Makes types print nicer with :type in most cases.
Previously, the printer expanded type aliases as much
as possible. Now, it defaults to a single level of expansion.
A later commit adds a #:verbose option to show the entire
type.
One problem with commit 299063d7c1
is that the new method for computing the lime green arrows no
longer has the information necessary to distinguish different
identifiers that come from the same require.
This means that, before this commit, mousing over an imported
identifier can be a real interactivity killer. So, instead of
adding more information to distinguish those ids, lets just
try not draw the lime green bubbles for imported identifiers
and see how that feels
that have overlapping ranges in the editor; also got rid of the
id-set stuff
Getting rid of the id-set information that was computed means that now
the mouse-over green bubbles, the "jump to next binding occurrence"/
"jump to bound occurrence" keybindings/menu items, and the renaming
are all being computed from the arrows information as needed, instead
of building up sets as check syntax collects information. This may
change the way Check Syntax behaves in some cases; so far the only
example I've found has been strange and are arguably for the
better. Specifically, this program
(define-syntax-rule (m x) (λ (x) x)) (m z)
no longer draws a green bubble when you mouse over the "z", since
there are no arrows (the only arrow that might have been drawn is
discarded since its start and end points are the same place).
This speeds up the "analyze the expanded code" phase of check syntax,
making it approximately 1.6x faster than before (going from about 31
seconds to about 19 seconds for this phase for the
drracket/private/unit.rkt file (on my machine)). Also, the replay
phase is probably a bit faster now, tho, too: there were 1.07x fewer
elements to process in the trace that comes back from online check
syntax now for that same file (33063 to 30842)
Note that this is only that one phase: this doesn't count the time to
actually expand the program (the dark blue bubble phase) nor the time
to send the results between places, nor the time to replay the
collected information (the light purple bubble phase).
Also combined expansion of in-generator for both expression and sequence
contexts, and made a number of places that were handling arity dynamically
to handle it statically instead.
Adds `--from-dir' and `--from-install' flags to select the interpretation
of the argument as a directory or as the name of an installed package.
Relevant to PR 13669
Adds `--as-is' (the default), `--source', and `--binary' flags to
select a pruning mode.
The `raco setup' tool recognizes a `rendered-scribblings' specification
in "info.rkt" to trigger moving rendered documentation into place,
registering its tags in the cross-reference database, and fixing up
references to "local-redirect.js"; the presence of a "synced.rktd"
indicates when those fixups have been performed (since, if the package
is installed in a user-specific scope, the documentation doesn't actually
move anywhere). Finally, "out<n>.sxref" needs to report paths relative to
the documentation's directory, and then the relative-directory references
need to be suitably resolved at derserialization; some support for such
relative paths was in place, but it wasn't quite general enough before.
Even though "info.rkt" files are in collections, `raco setup'
treats them in a directory-specific way --- and that's necessary
for specifying things like `compile-omit-files' in a collection
splice.
Make drest a list instead of a pair, replace an int-err with a match error
which has source location, and remove static name for rest argument in error
case.
When starting a thread, the thread was created and partially
initialized before trying to get a name for the thread from the given
thunk, but getting a name for the thunk could trigger scheduler
descisions, which could get confused by the partially initialized
thread.
