You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
IIRC we used to have a cargo feature to control whether we run the Stacked Borrows cache consistency checks. At some point I replaced that by cfg!(debug_assertions). For debug builds of Miri, the assertions don't make a huge difference. (In a quick benchmark with time ./miri test, I can't even see a difference.)
But we're getting Miri to work better in x.py, and that tends to be configured to use release builds with debug assertions. I don't think we want the cache consistency check running as part of ./x.py test library/core --miri, even if one has debug assertions enabled for the compiler. So I think we should go back to using an off-by-default feature flag for this.
The text was updated successfully, but these errors were encountered:
IIRC we used to have a cargo feature to control whether we run the Stacked Borrows cache consistency checks. At some point I replaced that by
cfg!(debug_assertions)
. For debug builds of Miri, the assertions don't make a huge difference. (In a quick benchmark withtime ./miri test
, I can't even see a difference.)But we're getting Miri to work better in
x.py
, and that tends to be configured to use release builds with debug assertions. I don't think we want the cache consistency check running as part of./x.py test library/core --miri
, even if one has debug assertions enabled for the compiler. So I think we should go back to using an off-by-default feature flag for this.The text was updated successfully, but these errors were encountered: