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

Catch2 doesn't allow inline debugbreaks #1279

Open
baldurk opened this Issue May 7, 2018 · 5 comments

Comments

Projects
None yet
3 participants
@baldurk

baldurk commented May 7, 2018

Description

In Catch 1.0, by default if you had debug breaks enabled they would be in-lined using macros so they appeared in the same stack frame on the line of the failed assertion. Then if you enabled CATCH_CONFIG_FAST_COMPILE it would turn that off and make the debugbreak happen in a function one stack frame away.

In Catch 2.0, only the fast-compile codepath exists in this respect, there is no way to have debug breaks on the same line. This was changed in 9329d97. I agree that it's likely a better default, but for me I'd like to have a way to opt back in. It's significantly nicer to have the debugger stop directly on a failed assertion instead of having to always switch up the stack frame, especially if you care about multiple assertions.

I hacked something up locally just by adding a CATCH_CONFIG_INLINE_DEBUG_BREAK which moves catch_debugger.h up into the public section, and calls CATCH_BREAK_INTO_DEBUGGER from INTERNAL_CATCH_REACT if breaks are enabled.

Note: Regardless of whether this is implemented the docs should be updated, since at the moment the docs for CATCH_CONFIG_FAST_COMPILE still mention the old inlined debug break behaviour as the default which is inaccurate.

Extra information

  • Catch version: v2.2.2
  • Operating System: Windows 7
  • Compiler+version: MSVC 2015
@sirdemios

This comment has been minimized.

sirdemios commented May 11, 2018

Could you post your code change. I'm not sure what you mean for how you call CATCH_BREAK_INTO_DEBUGGER. Do you mean you reverted the definition of INTERNAL_CATCH_REACT to what it was before the revision?

@sirdemios

This comment has been minimized.

sirdemios commented May 11, 2018

actually I ended up just making my own main so that visual studios has control over the program and can therefore have break points. Easy enough to do that its odd its not just in the basic tutorial.

@horenmar

This comment has been minimized.

Member

horenmar commented May 12, 2018

Interestingly, during my informal search I haven't really found many people using the -b flag, much less those who prefer the old behaviour.

@baldurk

This comment has been minimized.

baldurk commented May 12, 2018

For what it's worth I don't run with the -b flag, I have a custom main which automatically sets shouldDebugBreak based on whether a debugger is already attached or not.

I prefer having the breaks happen actually on the failed checks otherwise it's busy work every time a check fails to click back on the right stack frame. I realise it's a trade-off against compile time but it's one I'll happily make for a smoother experience.

@horenmar

This comment has been minimized.

Member

horenmar commented May 14, 2018

That sounds almost exactly like what -b does, as Catch first checks for attached debugger before trying to break.

Anyway, I'll see about adding this feature back, but lately a lack of maintainer time has been a real issue so ETA may vary.

horenmar added a commit that referenced this issue Jun 30, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment