debugging/stepping about miri HOT 6 CLOSED

What's wrong with the iterator method? It seems strictly more general to me. If we had the async stuff that has been proposed night not even be so painful!

from miri.

What's wrong with the iterator method?

We'd have to keep state inside miri. This way the state is the current execution of miri.

from miri.

Hmm, I'll have to actually look at the code and not just follow the issues to see what you mean :).

from miri.

AFAIK the main problem is Operand::Constant, which can occur in a myriad of locations, but requires evaluating more MIR. This is where generators would be nice.

Could do constant instantiation ahead of time before running code in the function, I suppose?

from miri.

I think it's mainly a question of whether to restructure the code around the iterator model (thus requiring state + possibly re-loading of some information at each step) or keeping the current structure (which is optimized for interpretation) and simply adding the various points where the code can be stopped.

Restructuring around an iterator model is possible, but it limits the possibilities (breaking at arbitrary points during interpretation, not just at statements) and creates unintuitive control flow.

from miri.

miri has been restructured around a stepping model. No measurable performance loss in some micro benchmarks.

from miri.