Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop support for missing MIR #211

Closed
2 tasks done
oli-obk opened this issue Jun 23, 2017 · 8 comments · Fixed by #566
Closed
2 tasks done

Drop support for missing MIR #211

oli-obk opened this issue Jun 23, 2017 · 8 comments · Fixed by #566
Labels
C-project Category: a larger project is being tracked here, usually with checkmarks for individual steps

Comments

@oli-obk
Copy link
Contributor

oli-obk commented Jun 23, 2017

Stuff to do

  • use exchange_malloc in the box unop
  • remove the hacks that catch some common missing MIR functions
@eddyb
Copy link
Member

eddyb commented Jun 23, 2017

cc @RalfJung

@RalfJung
Copy link
Member

Sounds fair enough. I am not sure about the first point -- I actually feel like miri really should have some more sophisticated logging infrastructure, so that I can selectively turn on/off tracing for different modules or so. And some things are pretty hard to see despite all the verbosity of a full trace, like which arguments are passed on a function call.

I suppose this is blocked by #202?

@oli-obk
Copy link
Contributor Author

oli-obk commented Jun 23, 2017

You can already do the module-wise logging. We use env_logger

@RalfJung
Copy link
Member

Okay so it's mostly a matter of documentation then. And maybe of organizing things do that the outputs of individual modules make more sense. ;) Like, I may want to say "trace instructions that are executed", which should exactly print every stmt and terminator that is executed, and nothing else. But I don't want to see details like symbol resolution or vtable caches.

@oli-obk
Copy link
Contributor Author

oli-obk commented Aug 2, 2017

We can remove the blocker on #202 by

a) adding appveyor and a travis mac build
b) enabling MIR generation unconditionally for the standard library
c) fixing rust-lang/rust#36501

Though a) would remove the feature that miri can easily interpret stuff for other targets.

@oli-obk
Copy link
Contributor Author

oli-obk commented Sep 27, 2017

One checkbox solved by #351

@RalfJung RalfJung added C-enhancement Category: a PR with an enhancement or an issue tracking an accepted enhancement C-project Category: a larger project is being tracked here, usually with checkmarks for individual steps and removed K-refactor labels Nov 17, 2018
@RalfJung
Copy link
Member

RalfJung commented Dec 2, 2018

I think we are basically ready to do this -- except that #202 is still open. @oli-obk do you think that should block this? Can we at least get a Travis runner with a 32bit platform to make sure those are covered for a unix system as well?

Also you added "add some flag to not report the libstd boilerplate in MIRI_LOG" to the list. That'd be nice to have but I'd prefer to not block on this, and open an issue instead.

@oli-obk
Copy link
Contributor Author

oli-obk commented Dec 3, 2018

I moved it out to a separate issue.

@RalfJung RalfJung added C-project Category: a larger project is being tracked here, usually with checkmarks for individual steps and removed C-project Category: a larger project is being tracked here, usually with checkmarks for individual steps C-enhancement Category: a PR with an enhancement or an issue tracking an accepted enhancement labels Jul 1, 2019
erickt pushed a commit to erickt/miri that referenced this issue Feb 4, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-project Category: a larger project is being tracked here, usually with checkmarks for individual steps
Projects
None yet
3 participants