Although the JIT would not try to use a block of shared code for more
than a certain number of arguments, it could in rare cases (related to
self tail calls, for example) generate the code and attempt to install
it in the array of shared-code pointers.
When an array value is provided, make sure that it's an array
with at least the expected length (or longer) and same element
layout. That's weaker than checking that the array elements have
the right type, because an `eq?` check at the ctype layer seems
too strong, and the ctype API doesn't provide enough information
for a more flexible equality.
This push makes the exn:misc:match exception transparent. This
matches other racket-raised user exceptions.
The motivation for this change was breakage in the handin-server;
specifically, the discussion in
https://groups.google.com/forum/#!topic/racket-users/nEos3-osoWE
...in which the handin-server was not behaving the same on exn:misc:match
because it was not transparent. This caused the handin server to
refuse to rewrite these exceptions, resulting in less helpful
messages for users.
The previous fix (1acaf011) caused a performance regression
(compilation time?), reported by stchang. Reverting to quote.
Apparently, the problem with gensym and deterministic compilation
isn't the uninterned-ness; it's the global counter used for the
name. So use a compilation-local counter instead.
Avoid creating a result that is intended as a module path but
has elements that are not syntactically allowed, such as a "."
in a collection-path element.
A phase shift was mising on `begin-for-syntax`es introduced by
`syntax-local-lift-module-end-declaration`, which is in turn
used to implement` module+`, so `module+` didn't work under
two or more `begin-for-syntaxes`.
Closes#1312
Syntax objects generally make sense as properties in other syntax
objects, but they require special care when marshaling to bytecode
(as syntax objects do in general). To make that special handling
possible and reliable, constrain the shape of allowed values.
The name `path-extension` created a conflict for an existing
registered package, so it should not have been added to
`racket/path`.
Also, `path-get-extension` was intended to work on a path
that is syntactically a directory, so fix and test that.
Change the one expansion mode as far as I can tell) that disables
lifts so that lifts are now allowed, which means that
`(syntax-transforming?)` implies `(syntax-transforming--with-lifts?)`.
The old documentation incorrectly characterized when lifts
were allowed. Ryan noticed the documentation problem, and that
observation led to this simplication.
Although excessive fragmentation is already detected at the end
of a major GC, it can get out of hand already during a long
incremental phase. So, check for excessive fragmentation and
bail out to a major GC when it happens.
Related to PR 15287
Fixes a failure in the web server tests caused by d23b296627.
Formerly, `(string->url "http://racket-lang.org")`, with no trailing
slash, would produce a `url` structure with `path-absolute?` as #f.
That doesn't exactly make sense, because a URL with a host must always
have an absolute path component. Claiming a relative path component
interacts badly with extending a URL with a path later. (Although
`combine-url/relative` compenstate, a similar function in the web
server doesn't.) The revised `url->string` always sets `path-absolute?`
to #t when a host is present, and whether the path is empty or contains
an empty string still records whether a trailing "/" was present.
The `url->string` function, meanwhile, now needs to use whether the
path is empty to determine whether a "/" should be added after
the host name, not whether `path-absolute?` is true.
This is a partial solution to the ~and problem, only for side clauses.
In (~and p1 p2 p3), one often wants errors in p2 to take precedence over
errors in p1, and likewise for p3 over p2. One solution is ~commit, but
that prevents backtracking. Another is ~post, but then two ~post wrappers
are needed around p3. Also, it doesn't make sense to compare progress of
the third #:with clause from stxclass A to the second #:with clause of
stxclass B and say third beats second.
So, generalize 'post to (post group index); post frames are comparable to
each other only if group is the same, then compared by index. (Post still
beats CAR and CDR.) Each set of side clauses shares a group.
For simplicity of code generation for now, use gensyms to identify groups.
