[rustdoc] Implementors section of Sync (and other similar traits) should separate implementors and !implementors

The !Sync implementations and the Sync implementations really ought to be separated apart, otherwise it makes it harder to skim.

https://doc.rust-lang.org/stable/std/marker/trait.Sync.html#implementors

Would it work out if the impls were just sorted apart, rather than giving an entirely new section heading to "negative impls"? That might be easier to implement.

@QuietMisdreavus

@QuietMisdreavus yes, just sorted seperately would be A+

Excellent!

Some mentoring instructions:

The code that displays all these impls is right here:

rust/src/librustdoc/html/render.rs

Lines 2860 to 2900 in 5205ae8

    
                   let (local, foreign) = implementors.iter() 
        
                       .partition::<Vec<_>, _>(|i| i.inner_impl().for_.def_id() 
        
                                                    .map_or(true, |d| cache.paths.contains_key(&d))); 
        
                   let (synthetic, concrete) = local.iter() 
        
                       .partition::<Vec<_>, _>(|i| i.inner_impl().synthetic); 
        
                   if !foreign.is_empty() { 
        
                       write!(w, " 
        
                           <h2 id='foreign-impls' class='small-section-header'> 
        
                             Implementations on Foreign Types<a href='#foreign-impls' class='anchor'></a> 
        
                           </h2> 
        
                       ")?; 
        
                       for implementor in foreign { 
        
                           let assoc_link = AssocItemLink::GotoSource( 
        
                               implementor.impl_item.def_id, &implementor.inner_impl().provided_trait_methods 
        
                           ); 
        
                           render_impl(w, cx, &implementor, assoc_link, 
        
                                       RenderMode::Normal, implementor.impl_item.stable_since(), false)?; 
        
                       } 
        
                   } 
        
                   write!(w, "{}", impl_header)?; 
        
                   for implementor in concrete { 
        
                       render_implementor(cx, implementor, w, &implementor_dups)?; 
        
                   } 
        
                   write!(w, "</ul>")?; 
        
                   if t.auto { 
        
                       write!(w, "{}", synthetic_impl_header)?; 
        
                       for implementor in synthetic { 
        
                           synthetic_types.extend( 
        
                               collect_paths_for_type(implementor.inner_impl().for_.clone()) 
        
                           ); 
        
                           render_implementor(cx, implementor, w, &implementor_dups)?; 
        
                       } 
        
                       write!(w, "</ul>")?; 
        
                   }

All the collections it's partitioning at the start of that contain render::Impl structs, and you can see whether it's a !impl by checking the "polarity" of the clean::Impl it contains. You can check implementor.impl_item().polarity and compare it against Some(clean::ImplPolarity::Negative), and sort these collections before iterating (or partition them farther, heh) to print one before the other. Given the nature of Send and Sync, i think it would be better to print the negative impls before the positive ones.

I can start on this one

@SLaabsDev

@SLaabsDev Thanks! Were the instructions i gave a good start? If you need any help, please ask me!

@QuietMisdreavus

@QuietMisdreavus Yes, the instructions were very helpful! I have it to a point where it is sorting with negative implementors showing first. One question I have is outside of the polarity does the order of implementors need to be preserved?

@SLaabsDev

@SLaabsDev That's probably best addressed by all of @rust-lang/docs but what i would say is "don't worry about it", since we currently don't do a very good job of keeping that ordering in the first place. This could be a good place to enforce a good ordering, but you don't have to do that in your PR. (If you asking to choose between sort and sort_unstable, go ahead and pick sort just so we don't disrupt the current ordering too much.)

Any update here?

Still in progress.

Opened #142380.

Thanks for looking at this after all these years!

If you're patient enough, everything (hopefully) will be done at some point. 😆

Rollup merge of rust-lang#142380 - GuillaumeGomez:neg-implementors, r…

Unrolled build for #142380

Rollup merge of #142380 - GuillaumeGomez:neg-implementors, r=yotamofek

Navigation Menu

Repository navigation

[rustdoc] Implementors section of Sync (and other similar traits) should separate implementors and !implementors #51129

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	let (local, foreign) = implementors.iter()
	.partition::<Vec<_>, _>(\|i\| i.inner_impl().for_.def_id()
	.map_or(true, \|d\| cache.paths.contains_key(&d)));


	let (synthetic, concrete) = local.iter()
	.partition::<Vec<_>, _>(\|i\| i.inner_impl().synthetic);


	if !foreign.is_empty() {
	write!(w, "
	<h2 id='foreign-impls' class='small-section-header'>
	Implementations on Foreign Types<a href='#foreign-impls' class='anchor'></a>
	</h2>
	")?;

	for implementor in foreign {
	let assoc_link = AssocItemLink::GotoSource(
	implementor.impl_item.def_id, &implementor.inner_impl().provided_trait_methods
	);
	render_impl(w, cx, &implementor, assoc_link,
	RenderMode::Normal, implementor.impl_item.stable_since(), false)?;
	}
	}

	write!(w, "{}", impl_header)?;
	for implementor in concrete {
	render_implementor(cx, implementor, w, &implementor_dups)?;
	}
	write!(w, "</ul>")?;

	if t.auto {
	write!(w, "{}", synthetic_impl_header)?;
	for implementor in synthetic {
	synthetic_types.extend(
	collect_paths_for_type(implementor.inner_impl().for_.clone())
	);
	render_implementor(cx, implementor, w, &implementor_dups)?;
	}
	write!(w, "</ul>")?;
	}

[rustdoc] Implementors section of Sync (and other similar traits) should separate implementors and !implementors #51129

Description

Activity

QuietMisdreavus commented on Jun 14, 2018

alex commented on Jun 14, 2018

QuietMisdreavus commented on Jun 14, 2018

SLaabsDev commented on Jun 22, 2018

QuietMisdreavus commented on Jun 23, 2018

SLaabsDev commented on Jun 26, 2018

QuietMisdreavus commented on Jul 3, 2018

hkBst commented on Feb 7, 2025

GuillaumeGomez commented on Feb 7, 2025

GuillaumeGomez commented on Jun 11, 2025

alex commented on Jun 11, 2025

GuillaumeGomez commented on Jun 11, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions