Skip to content

Use annihilator in cleanup_task #2676

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

Closed
graydon opened this issue Jun 21, 2012 · 3 comments
Closed

Use annihilator in cleanup_task #2676

graydon opened this issue Jun 21, 2012 · 3 comments
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@graydon
Copy link
Contributor

graydon commented Jun 21, 2012

Currently disabled.

@bblum
Copy link
Contributor

bblum commented Jun 27, 2012

The annihilator runs during task failure, but it's unclear if it's desirable on success. We'd lose the ability to detect leaked boxes.

@pcwalton
Copy link
Contributor

pcwalton commented Aug 7, 2012

Going to close this as invalid; the annihilator should be a no-op on task success.

@pcwalton pcwalton closed this as completed Aug 7, 2012
RalfJung pushed a commit to RalfJung/rust that referenced this issue Nov 17, 2022
empty commit to go through bors

Go through bors once to clean up after the force push, have CI run, all the usual.
@rust-log-analyzer
Copy link
Collaborator

The job mingw-check failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

RalfJung pushed a commit to RalfJung/rust that referenced this issue Nov 20, 2022
empty commit to go through bors

Go through bors once to clean up after the force push, have CI run, all the usual.
Aaron1011 pushed a commit to Aaron1011/rust that referenced this issue Jan 6, 2023
empty commit to go through bors

Go through bors once to clean up after the force push, have CI run, all the usual.
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
rust-lang#2676)

Parts of the compiler relies on the existence of some constructs that are available in the standard library and Kani library. However, they aren't available when we are actually building the standard library (`std-lib-regression.sh`) and the Kani libraries (when building the sysroot with `cargo build-dev`).

Thus, we introduce a flag to inform the compiler that we are currently building the standard library. This flag can then be used to properly enable / disable sysroot dependent code.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

No branches or pull requests

4 participants