POSIX and ANSI specify that char is always 1 byte, and I'm almost
certain that no systems violate this. Regardless, the SIZEOF_CHAR macro
is never used.
Allow `system-type` on non-Windows platforms to run `uname` to get
machine information, even in a sandbox or other contexts with a
limiting secutiry guard.
Check that it works to apply a continuation that shares with
an enclosing continuation, where a runstack overflow happens
between the continuations.
Closes PR 15281
While expanding a module, the root of module-relative references is a
fresh notion of "this module".
After expansion, "this module" is shifted to "an expanded module",
which is a global constant (for top-level modules). When an expanded
module is re-expanded, "an expanded module" is shifted to a fresh
"this module" during re-expansion, and so on.
One problem with this approach is that the shift from "this module" to
"an expanded module" isn't applied to syntax properties --- but
there's some extra trickery to make it work out by mutating "this
module" to make it look like "an expanded module".
Submodule expansion introduces an intermediate "parent of this module"
that wasn't currently covered by the extra trickery, so fix that.
`->i` already supports method contracts (for use wihin `object-contract`,
whose `->i` support is tested, but undocumented), which would make `->im`
possible.
Unfortunately, that support is very incomplete, missing support for using
`this` in contracts, making this `->im` (or the undocumented `->i` +
`object-contract` combo) basically useless.
Once/if that is added, then this commit would enable `->im`. Until then,
it's mostly useful for future reference (hence will be reverted).
In the meantime, it's possible to use `->i` within class/object contracts
with an explicit `this` argument, so nothing critical is lost, just a tiny
shortcut.
Previously, on the example, the function was not anonymous, so no
`tempN' would appear on the error message.
The fixed example makes use of `flat-named-contract' on an anonymous
function, which resembles the snippet above it and demonstrates the
purpose of `flat-named-contract' better.
Support creating executables when the base executable has
sections after ".rsrc", as long as there's room to add
a section to the section table. The new resource data is
written to the end of the file and vitrual space, but the
old space needs to be recorded as a section to keep them
contiguous.
MSVC 2015 puts a ".reloc" section after ".rsrc".
because right now they are too noisy to be useful to anyone other
than contract system maintainers. Once the problems inside the contract
library itself is fixed, consider moving these back to warning
Collect common types of frame (eg message, literal, etc) and
report together. For literals, symbols, and other atoms, compress
multiple entries to list. For example:
before: "expected the identifier `X' or expected the identifier `Y'"
now: "expected one of these identifiers: `X' or `Y'"
Previously, syntax-parse would only report errors for one maximal
progress equivalence class (and generate a useless "and other errors
occurred" message). But approach to linearizing the tree of failures
behaved badly if there was too much branching even for a single progress
equiv class. So now it dumps all of the maximal failures into one pile
and tries to find shared "sync points" (frames and terms) to linearize
the failure tree.
In particular, this eliminates the "and other errors" message.
Also updated and improved comments.
use trace-printf for all of the printing (which logs to info@compiler/cm
already) and make all of the indentation printing use the nicer:
| | | | |
style, and avoid creating the indentation strings unless they are actually used
Repair a mismatch between `syntax-local-lift-expression` and the
way that `compile` tries to avoid creating bindings while
compiling a top-level `define` form.
Closes#1284 and #1282
The meaning of SI_KERNEL signals is not clear, but ignoring
them seems to let the process continue ok. (These signals show
up when running `typed-racket-test/main --int`.)
In some cases, complex variants of (if (not <expr>) tb fb) are not reduced.
Extract the type information of the tests in <expr> to use it in tb and fb.
This wouldn't matter if the dependencies recorded in the dep file were
exactly the same as the files that are actually loaded when a file is
required. But in the case of lazy-require (or, more accurately, when
the cm-accomplice library is used), the dependencies in the dep files
can include things that are, in some cases, not actually
required. This is no problem for raco setup, since it looks at all of
the files anyway, but it can cause a particularly bad interaction with
DrRacket's online compilation facility.
For example say there is some file, e.g., mzscheme/main that is
required lazily. So when you edit a file in DrRacket, it will traverse
the requires and lets say it sees that the of mzscheme/main's
dependencies need to be compiled. So it will compile that dependency,
and then the ormap in this commit will be shortcircuited, which will
cause CM to stop looking at dependencies and decide to compile
mzscheme/main. So DrRacket will compile mzscheme/main, and then
whatever other pending compiles were going on and DrRacket's online
check syntax will complete, but because the lazy require doesn't
triggered, mzscheme/main isn't actually loaded during compilation.
Now you make another edit to the buffer and the same thing happens
except this time it gets past that first dependency of mzscheme/main
because there is now a .zo file for it from the last go 'round. But
say there isn't one for the second dependency. So it compiles that
file and compiles mzscheme/main now for a second time, but still
doesn't look at the third and fourth (etc) dependencies of
mzscheme/main.
Overall, this means that the second time you edit you file in
DrRacket, it should have been quick for the expansion portion to
finish because, after all, everything has been compiled and should
have been cached in .zo files. But because of the short circuiting, it
the .zo files weren't actually created and so your second edit is also
slow to come back.
After this commit, because of the ormap, the second edit will be
faster.
One worry with this commit is that it might change something that
could cause raco setup to go slower. To test that, I applied only this
change to a fresh checkout and did a full build. I then deleted all zo
files in racket/share/pkgs and timed 'raco setup -D' twice (four times
total). Here are the timings I get. The version of the code that uses
ormap:
% ... delete .zo files ...
% time raco setup -D
real 9m2.354s
user 37m5.176s
sys 4m14.963s
% ... delete .zo files ...
% time raco setup -D
real 9m2.421s
user 37m43.793s
sys 4m23.111s
The version of the code that uses the change in this commit:
% ... delete .zo files ...
% time raco setup -D
real 8m58.852s
user 36m51.369s
sys 4m13.633s
% ... delete .zo files ...
% time raco setup -D
real 8m53.980s
user 37m40.262s
sys 4m23.692s
