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 unique hashes to type descriptors #3205

Closed
brson opened this issue Aug 15, 2012 · 4 comments
Closed

Add unique hashes to type descriptors #3205

brson opened this issue Aug 15, 2012 · 4 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@brson
Copy link
Contributor

brson commented Aug 15, 2012

For TLS and named service keys, making the keys types would be a very convenient way to make the interfaces type safe, e.g. let my_value: MyType = get_tls_value(). Unfortunately we don't have a way of comparing type descriptors right now, and type descriptors may be duplicated in each crate (I think). If type descriptors stored a unique hash, then we could compare types.

@brson
Copy link
Contributor Author

brson commented Sep 14, 2012

@pcwalton and I were discussing another option for comparing types. If we can guarantee that every nominal type's type descriptor is represented by a distinct pointer (there are no duplicates across crates) then we can use traits to restrict type comparisons to only nominal types.

Maybe something like this:

trait TypeEq {
  static fn eq<A: TypeEq, B: TypeEq>() -> bool;
}

Then TlsKey could derive from TypeEq.

It is possible to compare structural types so we should probably consider that someday we'll inevitably want an interface for that too.

@bstrie
Copy link
Contributor

bstrie commented Apr 29, 2013

I remember being excited about this idea, but it seems to have fallen off the radar. I'll nominate this for a milestone. Perhaps maturity 3?

@graydon
Copy link
Contributor

graydon commented Jun 13, 2013

I don't think comparing on types is ideal, since there might be multiple TLS keys of the same type. I wonder if we could just establish a special const expr or syntax extension that always evaluates to a new UUID or something?

@graydon
Copy link
Contributor

graydon commented Jun 13, 2013

filed as #7104, I think it's the right place for fixing TLS keys. Closing this one. Re-open if you disagree.

@graydon graydon closed this as completed Jun 13, 2013
bors pushed a commit to rust-lang-ci/rust that referenced this issue May 15, 2021
RalfJung pushed a commit to RalfJung/rust that referenced this issue Dec 5, 2023
also test simd_select_bitmask on arrays for less than 8 elements
jaisnan pushed a commit to jaisnan/rust-dev that referenced this issue Jul 29, 2024
GitHub closed the previous PR (rust-lang#3205) after I renamed a branch, hooray.

Change the implementation of `println!` & `eprintln!` with no arguments
to call `print!("\n")`
& `eprint!("\n")` respectively instead of producing no tokens. This is
what std does. [^println][^eprintln]

 
[^println]:
https://github.com/rust-lang/rust/blob/8c127df75fde3d5ad8ef9af664962a7676288b52/library/std/src/macros.rs#L140
[^eprintln]:
https://github.com/rust-lang/rust/blob/8c127df75fde3d5ad8ef9af664962a7676288b52/library/std/src/macros.rs#L218

Resolves rust-lang#3204.

A test included, as per
model-checking/kani#3205 (comment)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one. 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

3 participants