Conversation
| /// Stores memory for globals (statics/consts). | ||
| pub(crate) alloc_map: interpret::AllocMap<'tcx>, | ||
|
|
||
| pub stack_protector: Lock<FxHashSet<DefId>>, |
There was a problem hiding this comment.
This is not correct for incremental (it's good enough to collect some data but would have to be fixed before merging). One implementation strategy I would try is to use the same mechanism as the (I forgot how exactly it's called) inferred function attrs thing pcwalton implemented a while ago.
There was a problem hiding this comment.
Yea, I think so. I'm trying to think of a more convenient way than adding a new query
There was a problem hiding this comment.
Thanks! I will learn the strategy you mentioned.
This comment has been minimized.
This comment has been minimized.
|
Let's just call it |
|
☔ The latest upstream changes (presumably #142492) made this pull request unmergeable. Please resolve the merge conflicts. |
MCP: rust-lang/compiler-team#841
This draft PR is a prototype for Rust's stack protection option.
The following are the initially proposed function check rules for rusty mode that require stack protection in Rust(Reference for clang here):
Arrays and references/pointers in Rust are of different types. If you want to use an array to manipulate stack space to cause a buffer overflow, you must first obtain a reference/pointer to it. Therefore, there is no need to specify stack protection rules for arrays in Rust.
Problems that require further discussion:
And changes to
GlobalContextneed to be avoided. I'm trying to think of a more convenient way than adding a new query.r? @ghost