When an overriden method implements a subtype of the superclass
type, sometimes the typechecker gets confused what the type should
be in the resulting class type.
original commit: 85b70aef7f66f0e0c8716fca716d1e38478bf763
In some situations, with-type would fail to clean up its
state before reporting an error at the top-level.
original commit: 591147dd028d4586e4346d83706d38454f043172
Since we resolve under Instance types for subtyping we
need to put them in the current-seen list too. Fixes
an infinite loop bug in subtyping.
original commit: 826a08d80c65d00dc0b77c89e4a6c2967bfef74c
This check was not really necessary to begin with,
but I thought it might be a useful sanity check. In
retrospect, calling `subtype` here causes other headaches
(such as when registering type aliases) and is confusing
when multiple #:implements are provided.
Instead, the #:implements clauses are just linearized
and the last type for any given method/field is taken.
This may also prevent a heisenbug that occurs in the
GUI framework types. I still don't know the root cause of
that non-determinism though.
Closes PR 14669
original commit: 9b4e3befa3605851f1ee30f20f4a38edd06dd8a9
This broke when I made the printing lazier using thunks.
Also use regexps for the tooltip tests.
original commit: 8bff995f41be53c119d4d09cb802b1f8c8f5c714
The use of case-> can cause an expression to get
typechecked multiple times, so the tooltips should reflect
all of the passes.
original commit: c170b8288c74dfd227f90897c4f65979a006cb68
Macros often expand into forms where the subforms have
the same syntax location as the entire form, which means
a naive approach gives confusing type tooltips on macro
expressions.
Instead, only keep the latest (outermost) type tooltip
for a given expression.
We could instead compute whether a given piece of syntax
is a subform of another at a given location or not, but
that check is expensive and we don't want to do that on
every update of the type table.
original commit: c2abbc700d6b8233e4a52f518d8056579d696b5f
Needs a real fix in the future to actually support this case.
Noted in a program from Matthias Felleisen.
Fixes PR 14841.
original commit: a64dadc78c54fc04bfa8ac8ae9649f4178f0ae25
This commit uses memoization not just for Name types
but for static contracts for all types. It also adjusts
how Name contracts are generated to increase sharing
across multiple type->contract calls.
original commit: 18c1f095fcf47e0b935819ecb0c3f2b7a3e7fec1
This was used for the old method of generating contracts
for these types but is no longer necessary.
original commit: 4d46985e58a0eb9ebe7cbe45063b6a28938df067
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.
original commit: b374902bf3dd24e06f64017aa3d89e29ec6ffd42
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.
original commit: 7b6ae09a2dcf04a5755f6f9256ff82369cc52403
