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.

Sign up for GitHub

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

Jump to bottom

Merge def_mod and def_ty maybe #3784

Closed
pcwalton opened this issue Oct 16, 2012 · 10 comments
Closed

Merge def_mod and def_ty maybe #3784

pcwalton opened this issue Oct 16, 2012 · 10 comments
Labels
A-resolve Area: Name resolution C-cleanup Category: PRs that clean code up or issues documenting cleanup.

Comments

@pcwalton
Copy link
Contributor

Might simplify some code now that they're in one namespace.
@graydon
Copy link
Contributor

graydon commented Mar 25, 2013

non-critical for 0.6, de-milestoning

@graydon
Copy link
Contributor

graydon commented May 15, 2013

#6501 is in the queue, should land shortly

@june0cho
Copy link
Contributor

Why should they be merged?

@metajack
Copy link
Contributor

Visiting for triage.

Paging @pcwalton for clarification.

This isn't user visible so not nominating.

@thestinger
Copy link
Contributor

I don't think this has happened, but all the names have been changed so it's bit hard to figure out exactly what was meant here.

@steveklabnik
Copy link
Member 

steve@computer:~/src/rust$ git grep def_mod
steve@computer:~/src/rust$ git grep def_ty
src/librustc/middle/resolve.rs:                        // (The pattern matching def_tys 
src/librustc/middle/ty.rs:macro_rules! def_type_content_sets(
src/librustc/middle/ty.rs:def_type_content_sets!(
steve@computer:~/src/rust$

Yup. These names are now totally gone. @pcwalton do you know what they changed into, and if this is relevant still?

@pcwalton
Copy link
Contributor Author

They changed to DefMod and DefTy

@frewsxcv
Copy link
Member

frewsxcv commented Feb 2, 2015

Triage: I can confirm that DefMod and DefTy still live in the codebase

DefMod

DefTy

@petrochenkov
Copy link
Contributor

This can be closed now, I believe.
def_mod and def_ty are now Def::{Mod, Enum, TyAlias and maybe Struct} and they are often used after resolve, when types and modules are treated very differently.

@arielb1
Copy link
Contributor

arielb1 commented Feb 14, 2016

I think this was fixed.

@arielb1 arielb1 closed this as completed Feb 14, 2016
RalfJung pushed a commit to RalfJung/rust that referenced this issue Sep 8, 2024
@bors
Auto merge of rust-lang#3784 - Mandragorian:detect_moved_mutexes, r=R…
18d358c 
…alfJung

Detect when pthread_mutex_t is moved

What I am not sure about this PR is how to support storing the additional mutex data like its address and kind. If I understand correctly the `concurrency::sync::Mutex` struct is to be used by any mutex implementation. This possibly means that different implementation might want to store different data in the mutex. So any additional data should be implementation defined somehow. Solutions that come to mind:

- Store the additional data as `Box<dyn Any>` and the implementations can downcast their data when they fetch them.
- Have each shim implementation define a `static mut` map between `MutexID`s and the additional data.

Let me know

Fixes rust-lang#3749
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-resolve Area: Name resolution C-cleanup Category: PRs that clean code up or issues documenting cleanup.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
9 participants
@graydon @steveklabnik @metajack @pcwalton @frewsxcv @thestinger @arielb1 @june0cho @petrochenkov