Skip to content

add a NonManaged kind #10869

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
thestinger opened this issue Dec 9, 2013 · 1 comment
Closed

add a NonManaged kind #10869

thestinger opened this issue Dec 9, 2013 · 1 comment
Labels
A-type-system Area: Type system E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@thestinger
Copy link
Contributor

This is needed to implemented weak pointers for reference counted pointers without adding explicit support in the compiler. They unable to allocate/deallocate with ~T because the object and allocation may have to be separately freed.

A dead simple implementation: https://github.com/thestinger/rust-core/blob/master/core/weak.rs

@thestinger
Copy link
Contributor Author

It's unclear if this will be necessary. It's a problem for a garbage collector implementation to deal with.

flip1995 pushed a commit to flip1995/rust that referenced this issue Jun 30, 2023
[`allow_attributes`, `allow_attributes_without_reason`]: Ignore attributes from procedural macros

I use `lint_reasons` and `clap`, which is a bit overzealous when it comes to preventing warnings in its macros; it uses a ton of allow attributes on everything to, as ironic as it is, silence warnings. These two now ignore anything from procedural macros.

PS, I think `allow_attributes.rs` should be merged with `attrs.rs` in the future.

fixes rust-lang#10377

changelog: [`allow_attributes`, `allow_attributes_without_reason`]: Ignore attributes from procedural macros
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system 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

1 participant