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

Add an option to disable the use of the redzone #15696

Merged
merged 1 commit into from
Jul 16, 2014
Merged

Conversation

Zoxc
Copy link
Contributor

@Zoxc Zoxc commented Jul 15, 2014

Disabling the redzone is required in x86-64's kernel mode to avoid interrupts trashing the stack.

I'm not sure if decl_fn is the right place to tag all functions with noredzone. It might have interactions with external functions when linking with bitcode built without -C no-redzone although I see no reason to do that.

I'm not sure how to write a test inspecting the bitcode output for noredzone attributes on all functions either.

llvm::LLVMAddFunctionAttribute(llfn,
llvm::FunctionIndex as c_uint,
llvm::NoRedZoneAttribute as uint64_t)
}
Copy link
Member

Choose a reason for hiding this comment

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

This indentation seems a bit off for the unsafe block.

@alexcrichton
Copy link
Member

Like with #15698, this may be better done as a crate attribute rather than a flag, or are there times you would want to compile the same code but opt out of this option?

@Zoxc
Copy link
Contributor Author

Zoxc commented Jul 16, 2014

You would want to toggle the redzone on freestanding libraries which could be used both in kernel mode and user mode (like libcore).

Disabling the redzone is required in x86-64's kernel mode to avoid interrupts trashing the stack.
bors added a commit that referenced this pull request Jul 16, 2014
Disabling the redzone is required in x86-64's kernel mode to avoid interrupts trashing the stack.

I'm not sure if decl_fn is the right place to tag all functions with noredzone. It might have interactions with external functions when linking with bitcode built without -C no-redzone although I see no reason to do that.

I'm not sure how to write a test inspecting the bitcode output for noredzone attributes on all functions either.
@bors bors closed this Jul 16, 2014
@bors bors merged commit 036b9e8 into rust-lang:master Jul 16, 2014
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 13, 2023
…truct, r=Veykril

feat: implement tuple return type to tuple struct assist

This PR implements the `convert_tuple_return_type_to_struct` assist, for converting the return type of a function or method from a tuple to a tuple struct. Additionally, it moves the `to_camel_case` and `char_has_case` functions from `case_conv` to `stdx` so that they can be used similar to `to_lower_snake_case`.

[tuple_return_type_to_tuple_struct.webm](https://github.com/rust-lang/rust-analyzer/assets/52933714/2803ff58-fde3-4144-9495-7c7c7e139075)

Currently, the assist puts the struct definition above the function, or above the nearest `impl` or `trait` if applicable and only rewrites literal tuples that are returned in the body of the function. Additionally, it only attempts to rewrite simple tuple pattern usages with the corresponding tuple struct pattern but does so across files and modules.

I think that this is sufficient for the majority of use cases but I could be wrong. One thing I'm still not sure how to approach is handling `Self` and generics/lifetimes in the tuple type to be extracted. I was thinking of either manually figuring out what lifetimes and generics are in scope and using them (sort of similar to the `generate_function` assist) or maybe using `ctx.sema.resolve_type` and `generic_params` on `hir::Type` but this seems to not deal with lifetimes.

Closes rust-lang#14293
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.

3 participants