Custom Query (1030 matches)
Results (940 - 942 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #473 | fixed | ARGLIST-FROM-MAP confused by supplied-p variables | ||
| Description |
[I have a fix for this and will close this ticket as soon as I check it in; if I missed some case, we can re-open the ticket.] In the absence of better information, CCL:ARGLIST tries to construct a function's arglist from the function's symbol map (and lfun-bits.) Entries in the map generally appear in the reverse of the order in which variables come into scope, and supplied-p variables for optional args generally come into scope before subsequent optional args do; ARGLIST can't assume that ordered entries in the symbol map correspond to the names of arguments that can be passed by the caller unless we add some additional information or take some other steps to ensure this. (The "shape" of the argument list has been correct, but getting the names wrong can be confusing, especially since backtrace uses the same mechanism to identify arguments and other values.) |
|||
| #370 | fixed | AREF/ASET optimizations with undeclared rank | ||
| Description |
From gb:
declares that A and B are SIMPLE-ARRAYs with unspecified dimensionality. We'll generally only try to open-code the AREF/CCL::ASET if the dimensionality of the array is specified in the declaration. In "reasonably safe" code, if the declared dimensionality of the array was unpecified (or specified as *), we could treat
as
and typecheck that A is in fact a one-dimensional array of the declared type before doing anything with it. If A was in fact of the wrong dimensionality, we'd get a type error (A isn't a simple-one-dimensional-array of the specified type) rather than a wrong-number-of-subscripts error, but I don't think that AREF's error behavior is too rigidly specified. In unsafe code, we crash and burn if the actual dimensionality doesn't match, but win in more cases if it does. |
|||
| #293 | fixed | ADVISE makes functions cons | ||
| Description |
When a function is advised, it conses a small amount of memory every time it is called. It seems as if ADVISE-GLOBAL-DEF is at fault. It would be better if the encapsulation for the function would not allocate memory, i.e. to reduce overhead when profiling inner loops. |
|||
