Don't export type->contract except for testing. This
discourages direct use of type->contract in favor of
using the change-contract-fixup approach.
Also consolidate most of the contract-related syntax
properties into a single property containing a prefab
struct instance.
Eliminates the last remaining use of type->contract
outside of the type-contract.rkt file. This allows
all contract generation to go through a single point
of control.
Use the same mechanism as require/typed for doing all
contract gen for make-predicate, cast, etc. Also don't
special-case contract generation for top-level require/typed.
This change is needed for the more stringent Gatekeeper introduced in
Mac OS X 10.9.5, but the build machine has to be 10.9 or later to make
10.9.5 clients happy.
Some expression movements are limited by the possibility of retaining
a value in a way that interacts with space safety, but primitives that
return immediately shouldn't get in the way of those movements.
When a variable X is bound to an expression that implies properties of
other bindings, and if X is used only once and can be replaced by
its value expression, then further optimization of that expression must
not assume the properties that are established by evaluating the
expression.
Also, don't move expressions past unsafe operations, since the expression
might implicitly guard against unsafety.
Closes PR 14819
Line 11: "may" instead of "can"
Line 11: "implies" instead of "means"
Line 14: "states" instead of "means"
Line 17: -resources should be clear and separated-
I think that `-static-libgcc` didn't solve any problems with gcc
3.7.x, but with 3.8.x, divdi3() shows up, and that leads to
a "libgcc_s.dll" dependency unless `-static-libgcc` is used.
I don't see a reason to include `(find-dll-dir)` in the result of
`(get-lib-search-dirs)`. It's practically always redundant, and
including it causes problems for sandboxes --- since `(find-dll-dir)`
must inspect the Racket executable on Windows and Mac OS X, and that
access is normally not allowed by a sandbox.
Fix various configuration problems, and make the build work with 3m
(probably for the first time).
The repairs include corrections for the manual link table, but also
switch Cygwin to relying on normal DLL exports, instead, to work
properly with the FFI.
The `--enable-shared` comfiguration option is no longer required for
Cygwin. When it is used, the `gracket` launcher does not work right,
because the Cygwin DLL is in the "bin" directory and "gracket.exe" is
in the "lib" directory. Along similar lines, stand-alone executables
won't work with `--enable-shared`.
The change to `ffi/winapi` makes it match the documentation.
Originally, the symbolic "name" of a logger was just a string to
prefix any message sent to a logger. The symbol has evolved instead
into a first-class component of an event to be used for message
selection and filtering; the word "topic" more clearly communicates
that role.
This is just a documentation change. The `logger-name` function would
be better called `logger-default-topic`, but it's staying the same for
compatibility.
Based on comments from Tony Garnock-Jones.
These two functions allow the creation of relays that receive events
on logger B where there are interested receivers for logger A.
Based on comments from Tony Garnock-Jones.
With the new propagation-filtering support, CM's accomplice channel
doesn't need a receiver that accepts all events, and so less logging
logging work will be triggered during compilation.
Events to propagate to a parent are described in the same way
as events to receive for a log receiver. The default is still
to propagate all events to the parent, which corresponds to
a propagation specification of 'debug.
Making a propagation-filtering specification built-in, instead of
allowing arbitrary filter functions, keeps `log-level?` efficient and
avoid hooks that might be implemented by untrusted code.
The optional callback argument was added (by me) in f2d87085. This is
a backward-incompatible change, but allowing an arbitrary callback
on a logger now seems like an especially bad idea; forms like
`log-error` otherwise work in constrained contexts, while an arbitrary
callback function allows potentially untrusted code in those contexts.
Meanwhile, the addition doesn't satisfactorily solve the original
problem, since it intereferes with `log-level?` and similar filters.
