- 
                Notifications
    You must be signed in to change notification settings 
- Fork 13.9k
miri: accept extern types in structs if they are the only field #55672
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
          
     Merged
      
      
    
  
     Merged
                    Changes from 2 commits
      Commits
    
    
            Show all changes
          
          
            6 commits
          
        
        Select commit
          Hold shift + click to select a range
      
      e753d21
              
                miri: accept extern types in structs if they are the only field
              
              
                RalfJung aca76d4
              
                test for offset and alignment of the sized part, instead of field count
              
              
                RalfJung bb17f71
              
                also test with PhantomData
              
              
                RalfJung 5ebd077
              
                make it more obvious that the size is not relevant
              
              
                RalfJung a6622c2
              
                note some FIXMEs
              
              
                RalfJung ba0bab3
              
                make sure we only guess field alignment at offset 0
              
              
                RalfJung File filter
Filter by extension
Conversations
          Failed to load comments.   
        
        
          
      Loading
        
  Jump to
        
          Jump to file
        
      
      
          Failed to load files.   
        
        
          
      Loading
        
  Diff view
Diff view
There are no files selected for viewing
  
    
      This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
      Learn more about bidirectional Unicode characters
    
  
  
    
              
  
    
      This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
      Learn more about bidirectional Unicode characters
    
  
  
    
              
  
    
      This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
      Learn more about bidirectional Unicode characters
    
  
  
    
              
              | Original file line number | Diff line number | Diff line change | 
|---|---|---|
| @@ -0,0 +1,21 @@ | ||
| // compile-pass | ||
|  | ||
| // Test that we can handle newtypes wrapping extern types | ||
|  | ||
| #![feature(extern_types, const_transmute)] | ||
|  | ||
| extern "C" { | ||
| pub type ExternType; | ||
| } | ||
| unsafe impl Sync for ExternType {} | ||
|  | ||
| #[repr(transparent)] | ||
| pub struct Wrapper(ExternType); | ||
|         
                  RalfJung marked this conversation as resolved.
              Show resolved
            Hide resolved | ||
|  | ||
| static MAGIC_FFI_STATIC: u8 = 42; | ||
|  | ||
| pub static MAGIC_FFI_REF: &'static Wrapper = unsafe { | ||
| std::mem::transmute(&MAGIC_FFI_STATIC) | ||
| }; | ||
|  | ||
| fn main() {} | ||
  Add this suggestion to a batch that can be applied as a single commit.
  This suggestion is invalid because no changes were made to the code.
  Suggestions cannot be applied while the pull request is closed.
  Suggestions cannot be applied while viewing a subset of changes.
  Only one suggestion per line can be applied in a batch.
  Add this suggestion to a batch that can be applied as a single commit.
  Applying suggestions on deleted lines is not supported.
  You must change the existing code in this line in order to create a valid suggestion.
  Outdated suggestions cannot be applied.
  This suggestion has been applied or marked resolved.
  Suggestions cannot be applied from pending reviews.
  Suggestions cannot be applied on multi-line comments.
  Suggestions cannot be applied while the pull request is queued to merge.
  Suggestion cannot be applied right now. Please check back later.
  
    
  
    
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interestingly, we can make
size_and_align_oferror, but have a separatealign_ofthat works even forextern type. Only the alignment is used here, anyway!There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, you can also just move the
Optionto be around the size, but not the alignment.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could, but I'd rather wait for the decision to treat the
size_of_valandalign_of_valintrinsics asymmetrically before doing that.extern typewill likely get alignment 1 currently, which is likely not actually correct for the type they are opaquely representing, so I am a bit worried about unilaterally implementing such behavior.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can't access that alignment without first having a reference, so having it too high would be a problem (the assumption might not be guaranteed by what you're FFI-ing to), but having it too low wouldn't break anything (other than field offsets).
So the way I see it, the alignment is only a lower bound, and
1is fine, unless you want to use it as an aligned field in a struct.Anyway, my concern is also kind of a confusing code thing.
You could also add a
.map(|(_, align)| align)beforeunwrap_or_else, which would mean the code and the comment wouldn't mention the "size" of theextern type.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh that's a good point. We cannot create such references ourselves anyway as we cannot have data of that type.
Still I think miri shouldn't move ahead of the rest of the decision process here.
I will implement your
mapsuggestion.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I implemented what you suggested.