Remove fixed_stack_segment #10407
Merged
Remove fixed_stack_segment #10407
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hooray for removing features! |
These two attributes are no longer useful now that Rust has decided to leave segmented stacks behind. It is assumed that the rust task's stack is always large enough to make an FFI call (due to the stack being very large). There's always the case of stack overflow, however, to consider. This does not change the behavior of stack overflow in Rust. This is still normally triggered by the __morestack function and aborts the whole process. C stack overflow will continue to corrupt the stack, however (as it did before this commit as well). The future improvement of a guard page at the end of every rust stack is still unimplemented and is intended to be the mechanism through which we attempt to detect C stack overflow. Closes rust-lang#8822 Closes rust-lang#10155
I increased this to 4MB when I implemented abort-on-stack-overflow for Rust functions. Now that the fixed_stack_segment attribute is removed, no rust function will ever reasonably request 2MB of stack (due to calling an FFI function). The default size of 2MB should be plenty for everyday use-cases, and tasks can still request more stack via the spawning API.
bors
added a commit
that referenced
this pull request
Nov 11, 2013
The commit messages have more details, but this removes all analysis and usage related to fixed_stack_segment and rust_stack attributes. It's now the assumption that we always have "enough stack" and we'll implement detection of stack overflow through other means. The stack overflow detection is currently implemented for rust functions, but it is unimplemented for C functions (we still don't have guard pages).
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Mar 24, 2023
Use uninit checking from rustc rustc has proper heuristics for actually checking whether a type allows being left uninitialized (by asking CTFE). We can now use this for our helper instead of rolling our own bad version with false positives. I added this in rustc in rust-lang#108669 Fix rust-lang#10407 changelog: [`uninit_vec`]: fix false positives changelog: [`uninit_assumed_init`]: fix false positives
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The commit messages have more details, but this removes all analysis and usage related to fixed_stack_segment and rust_stack attributes. It's now the assumption that we always have "enough stack" and we'll implement detection of stack overflow through other means.
The stack overflow detection is currently implemented for rust functions, but it is unimplemented for C functions (we still don't have guard pages).