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

std: Funnel all aborts through rtabort! cc #31519 #32832

Closed
wants to merge 1 commit into from

Conversation

brson
Copy link
Contributor

@brson brson commented Apr 8, 2016

The abort strategy isn't necessarily as simple as intrinsics::abort. For example on windows we may want to instead use __failfast. All aborts should use the same code.

@rust-highfive
Copy link
Collaborator

r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

@brson
Copy link
Contributor Author

brson commented Apr 8, 2016

r? @alex

@brson
Copy link
Contributor Author

brson commented Apr 8, 2016

The only other use of the intrinsics is in the alloc crate.

@brson
Copy link
Contributor Author

brson commented Apr 8, 2016

r? @alexcrichton

@rust-highfive rust-highfive assigned alexcrichton and unassigned aturon Apr 8, 2016
panic. aborting.\n"));
unsafe { intrinsics::abort() }
rtabort!("thread panicked while processing \
panic. aborting.");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This means that these messages will now be prefixed with fatal runtime error: rather than being printed directly as-is. In the past I think we tried to avoid printing the "fatal runtime error" aspect?

@alexcrichton
Copy link
Member

Maybe we could add a function to do the abort without printing and use that instead in these places?

@brson
Copy link
Contributor Author

brson commented Apr 8, 2016

@alexcrichton If we removed the "fatal runtime error" part of the rtabort! message completely, turning the empty rtabort!() cases into nothing but the abort intrinsic, would that solve both problems?

@alexcrichton
Copy link
Member

Yeah I think that'd also work!

@bors
Copy link
Contributor

bors commented May 10, 2016

☔ The latest upstream changes (presumably #32900) made this pull request unmergeable. Please resolve the merge conflicts.

@alexcrichton
Copy link
Member

Closing due to inactivity, but we can always resubmit with some fixes later of course!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants