Bump bootstrap compiler to new beta

[Mark-Simulacrum]

https://forge.rust-lang.org/release/process.html#master-bootstrap-update-t-2-day-tuesday

[rustbot]

r? @albertlarsan68

rustbot has assigned @albertlarsan68.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

Some changes occurred to the CTFE / Miri engine

cc @rust-lang/miri

The Miri subtree was changed

cc @rust-lang/miri

[rustbot]

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

[lqd]

🤔

Documenting std v0.0.0 (/checkout/library/std)
2024-07-23T11:35:59.8005392Z thread 'rustc' panicked at library/core/src/slice/sort/shared/smallsort.rs:848:5:
2024-07-23T11:35:59.8008951Z Ord violation

rust/library/core/src/slice/sort/shared/smallsort.rs

Lines 837 to 843 in d111ccd

	// We now should have consumed the full input exactly once. This can
	// only fail if the comparison operator fails to be Ord, in which case
	// we will panic and never access the inconsistent state in dst.
	if left != left_end || right != right_end {
	panic_on_ord_violation();
	}
	}

[workingjubilee]

@Voultapher what do you think is up with

rust/src/librustdoc/html/render/print_item.rs

Lines 316 to 556 in 84c257e

	fn item_module(w: &mut Buffer, cx: &mut Context<'_>, item: &clean::Item, items: &[clean::Item]) {
	write!(w, "{}", document(cx, item, None, HeadingOffset::H2));
	let mut indices = (0..items.len()).filter(|i| !items[*i].is_stripped()).collect::<Vec<usize>>();
	// the order of item types in the listing
	fn reorder(ty: ItemType) -> u8 {
	match ty {
	ItemType::ExternCrate => 0,
	ItemType::Import => 1,
	ItemType::Primitive => 2,
	ItemType::Module => 3,
	ItemType::Macro => 4,
	ItemType::Struct => 5,
	ItemType::Enum => 6,
	ItemType::Constant => 7,
	ItemType::Static => 8,
	ItemType::Trait => 9,
	ItemType::Function => 10,
	ItemType::TypeAlias => 12,
	ItemType::Union => 13,
	_ => 14 + ty as u8,
	}
	}
	fn cmp(
	i1: &clean::Item,
	i2: &clean::Item,
	idx1: usize,
	idx2: usize,
	tcx: TyCtxt<'_>,
	) -> Ordering {
	let ty1 = i1.type_();
	let ty2 = i2.type_();
	if item_ty_to_section(ty1) != item_ty_to_section(ty2)
	|| (ty1 != ty2 && (ty1 == ItemType::ExternCrate || ty2 == ItemType::ExternCrate))
	{
	return (reorder(ty1), idx1).cmp(&(reorder(ty2), idx2));
	}
	let s1 = i1.stability(tcx).as_ref().map(|s| s.level);
	let s2 = i2.stability(tcx).as_ref().map(|s| s.level);
	if let (Some(a), Some(b)) = (s1, s2) {
	match (a.is_stable(), b.is_stable()) {
	(true, true) | (false, false) => {}
	(false, true) => return Ordering::Greater,
	(true, false) => return Ordering::Less,
	}
	}
	let lhs = i1.name.unwrap_or(kw::Empty);
	let rhs = i2.name.unwrap_or(kw::Empty);
	compare_names(lhs.as_str(), rhs.as_str())
	}
	match cx.shared.module_sorting {
	ModuleSorting::Alphabetical => {
	indices.sort_by(|&i1, &i2| cmp(&items[i1], &items[i2], i1, i2, cx.tcx()));
	}
	ModuleSorting::DeclarationOrder => {}
	}
	// This call is to remove re-export duplicates in cases such as:
	//
	// ```
	// pub(crate) mod foo {
	// pub(crate) mod bar {
	// pub(crate) trait Double { fn foo(); }
	// }
	// }
	//
	// pub(crate) use foo::bar::*;
	// pub(crate) use foo::*;
	// ```
	//
	// `Double` will appear twice in the generated docs.
	//
	// FIXME: This code is quite ugly and could be improved. Small issue: DefId
	// can be identical even if the elements are different (mostly in imports).
	// So in case this is an import, we keep everything by adding a "unique id"
	// (which is the position in the vector).
	indices.dedup_by_key(|i| {
	(
	items[*i].item_id,
	if items[*i].name.is_some() { Some(full_path(cx, &items[*i])) } else { None },
	items[*i].type_(),
	if items[*i].is_import() { *i } else { 0 },
	)
	});
	debug!("{indices:?}");
	let mut last_section = None;
	for &idx in &indices {
	let myitem = &items[idx];
	if myitem.is_stripped() {
	continue;
	}
	let my_section = item_ty_to_section(myitem.type_());
	if Some(my_section) != last_section {
	if last_section.is_some() {
	w.write_str(ITEM_TABLE_CLOSE);
	}
	last_section = Some(my_section);
	write_section_heading(
	w,
	my_section.name(),
	&cx.derive_id(my_section.id()),
	None,
	ITEM_TABLE_OPEN,
	);
	}
	let tcx = cx.tcx();
	match *myitem.kind {
	clean::ExternCrateItem { ref src } => {
	use crate::html::format::anchor;
	w.write_str(ITEM_TABLE_ROW_OPEN);
	match *src {
	Some(src) => write!(
	w,
	"<div class=\"item-name\"><code>{}extern crate {} as {};",
	visibility_print_with_space(myitem, cx),
	anchor(myitem.item_id.expect_def_id(), src, cx),
	myitem.name.unwrap(),
	),
	None => write!(
	w,
	"<div class=\"item-name\"><code>{}extern crate {};",
	visibility_print_with_space(myitem, cx),
	anchor(myitem.item_id.expect_def_id(), myitem.name.unwrap(), cx),
	),
	}
	w.write_str("</code></div>");
	w.write_str(ITEM_TABLE_ROW_CLOSE);
	}
	clean::ImportItem(ref import) => {
	let stab_tags = if let Some(import_def_id) = import.source.did {
	// Just need an item with the correct def_id and attrs
	let import_item =
	clean::Item { item_id: import_def_id.into(), ..myitem.clone() };
	let stab_tags = Some(extra_info_tags(&import_item, item, tcx).to_string());
	stab_tags
	} else {
	None
	};
	w.write_str(ITEM_TABLE_ROW_OPEN);
	let id = match import.kind {
	clean::ImportKind::Simple(s) => {
	format!(" id=\"{}\"", cx.derive_id(format!("reexport.{s}")))
	}
	clean::ImportKind::Glob => String::new(),
	};
	let stab_tags = stab_tags.unwrap_or_default();
	let (stab_tags_before, stab_tags_after) = if stab_tags.is_empty() {
	("", "")
	} else {
	("<div class=\"desc docblock-short\">", "</div>")
	};
	write!(
	w,
	"<div class=\"item-name\"{id}>\
	<code>{vis}{imp}</code>\
	</div>\
	{stab_tags_before}{stab_tags}{stab_tags_after}",
	vis = visibility_print_with_space(myitem, cx),
	imp = import.print(cx),
	);
	w.write_str(ITEM_TABLE_ROW_CLOSE);
	}
	_ => {
	if myitem.name.is_none() {
	continue;
	}
	let unsafety_flag = match *myitem.kind {
	clean::FunctionItem(_) | clean::ForeignFunctionItem(..)
	if myitem.fn_header(tcx).unwrap().safety == hir::Safety::Unsafe =>
	{
	"<sup title=\"unsafe function\">⚠</sup>"
	}
	clean::ForeignStaticItem(_, hir::Safety::Unsafe) => {
	"<sup title=\"unsafe static\">⚠</sup>"
	}
	_ => "",
	};
	let visibility_and_hidden = match myitem.visibility(tcx) {
	Some(ty::Visibility::Restricted(_)) => {
	if myitem.is_doc_hidden() {
	// Don't separate with a space when there are two of them
	"<span title=\"Restricted Visibility\">&nbsp;🔒</span><span title=\"Hidden item\">👻</span> "
	} else {
	"<span title=\"Restricted Visibility\">&nbsp;🔒</span> "
	}
	}
	_ if myitem.is_doc_hidden() => "<span title=\"Hidden item\">&nbsp;👻</span> ",
	_ => "",
	};
	w.write_str(ITEM_TABLE_ROW_OPEN);
	let docs =
	MarkdownSummaryLine(&myitem.doc_value(), &myitem.links(cx)).into_string();
	let (docs_before, docs_after) = if docs.is_empty() {
	("", "")
	} else {
	("<div class=\"desc docblock-short\">", "</div>")
	};
	write!(
	w,
	"<div class=\"item-name\">\
	<a class=\"{class}\" href=\"{href}\" title=\"{title}\">{name}</a>\
	{visibility_and_hidden}\
	{unsafety_flag}\
	{stab_tags}\
	</div>\
	{docs_before}{docs}{docs_after}",
	name = myitem.name.unwrap(),
	visibility_and_hidden = visibility_and_hidden,
	stab_tags = extra_info_tags(myitem, item, tcx),
	class = myitem.type_(),
	unsafety_flag = unsafety_flag,
	href = item_path(myitem.type_(), myitem.name.unwrap().as_str()),
	title = [myitem.type_().to_string(), full_path(cx, myitem)]
	.iter()
	.filter_map(|s| if !s.is_empty() { Some(s.as_str()) } else { None })
	.collect::<Vec<_>>()
	.join(" "),
	);
	w.write_str(ITEM_TABLE_ROW_CLOSE);
	}
	}
	}
	if last_section.is_some() {
	w.write_str(ITEM_TABLE_CLOSE);
	}
	}

that is causing it to hit this panic path in smallsort?

[tgross35]

Is it possible that the rustdoc side is now doing something less determinant with floats where there wasn't before? #126761 touched the rustdoc side (cc @GuillaumeGomez) slightly after #124032 merged.

But based on that description I can't even see how the branch should ever hit, given T: Ord...

[tgross35]

Cc also @orlp who collaborated on the sort algorithm (per the top note at #124032).

[orlp]

First, this code looks a bit suspect to me:

if item_ty_to_section(ty1) != item_ty_to_section(ty2)
    || (ty1 != ty2 && (ty1 == ItemType::ExternCrate || ty2 == ItemType::ExternCrate))
{
    return (reorder(ty1), idx1).cmp(&(reorder(ty2), idx2));
}

You can't just arbitrarily decide to sometimes order by type + index, and sometimes ignore it, and still expect to form a strict weak ordering.

What's even weirder is that if I look at item_ty_to_section, I believe that the above code is equivalent to the much simpler:

if ty1 != t2 {
    return reorder(ty1).cmp(&reorder(ty2));
}

which would be correct for a strict partial order. What was the intention of this branch?

---

Then we have the following, which is an actual Ord violation:

let s1 = i1.stability(tcx).as_ref().map(|s| s.level);
let s2 = i2.stability(tcx).as_ref().map(|s| s.level);
if let (Some(a), Some(b)) = (s1, s2) {
    match (a.is_stable(), b.is_stable()) {
        (true, true) | (false, false) => {}
        (false, true) => return Ordering::Greater,
        (true, false) => return Ordering::Less,
    }
}

Generally speaking, "order by property X if both objects have property X, otherwise ignore property X" does not form a strict weak ordering. Consider the following three objects:

type   stability   name
0      Some(2)     a
0      None        b
0      Some(1)     c

Here we simplify a bit and directly sort by type, then stability if both are Some, and then by name. Seems reasonable enough right? Nope, here you'll find that the objects with names a, b, c will sort like a < b < c < a, a clear Ord violation.

---

This then brings us to compare_names. This has an issue with a similar pattern:

// Then process the numeric part, if both sides have one (and they fit in a u64).
if let (Ok(ln), Ok(rn)) = (lb.parse::<u64>(), rb.parse::<u64>()) {
    match ln.cmp(&rn) {
        Ordering::Equal => (),
        x => return x,
    }
}

This violates strict weak ordering. Consider foo100000000000000000000, foo10, and foo2. The comparison function claims that foo10 < foo100000000000000000000 < foo2 < foo10.

[Voultapher]

@workingjubilee to my knowledge this panic can only happen when the comparison function does not implement a strict weak ordering. This is usually indicative of a logic bug. The old implementation quietly accepted such cases and produced some unspecified but arguably not sorted order.

[Voultapher]

But based on that description I can't even see how the branch should ever hit, given T: Ord

I think this interpretation is something we should consider, maybe a better panic description can help avoid confusion in the future. T: Ord only says that it's implemented, not that it is implemented correctly.

[tgross35]

Thanks Orson & Lukas for the detailed response. I suppose @rust-lang/rustdoc may want to take a look at a possible change here. The relevant bit was added in 2022 so I doubt anybody has any specific memory of why it exists as it currently does (#93830).

A PR to make the panic message more useful would be great, maybe even suggesting to double check T's implementation of Ord. Possibly worth a note in the docs as well.

[GuillaumeGomez]

This is very surprising. Checking what's going on.

[workingjubilee]

Thank you @orlp for the entomology!

Yes, I am familiar with the "T: Ord is not actually a mathematical, compile-time-checked proof that the trait is implemented correctly" issue, and actually rather like that we now panic on violating strict weak orderings. But I couldn't quite remember what "strict weak order" was at the time I first asked. Math brain isn't up before noon, you see.

Checking again, if I understand correctly a strict weak ordering is still satisfied by most of libstd's PartialOrd impls, yes? Like floats?

[orlp]

@workingjubilee Strictly speaking, yes strict weak ordering corresponds with PartialOrd.

I should've been more specific and required a total order, which is also what Ord requires. A total order is a strict weak ordering where all elements must be comparable.

If something violates a strict weak ordering it also violates a total order.

[Voultapher]

Small word of caution, the docs say "If T: Ord does not implement a total order, the implementation may panic.". We do catch strict weak ordering violations in many cases, but it's not guaranteed. One thing I like about our implementation in contrast to for example the recently added libc++ std::sort strict weak ordering checks, the libc++ one works by consuming a fixed number of comparison at the very start (20/50) IIRC and running a O(N^3) check algorithm on them, but only for debug builds. In contrast our implementation sits at the heart of the small-sort and notices issues that were caused by some higher level components, this way it holistically works for the hole input, catching violations with a high chance, plus it serves dual purpose as a safety safeguard that lets us avoid additional state tracking complexity, bailing before committing the faulty merge result. There are cases where this logic isn't used at all e.g. len <= 20, non Freeze types.

[GuillaumeGomez]

So is there anything for me to do on rustdoc side or...?

[bors]

☀️ Try build successful - checks-actions
Build commit: dcd20e4 (dcd20e4e85ed867c82731480b2bb1e0493a72e01)

[tgross35]

New theory new test #128331. (edit: that worked).

I think a lot of people are waiting on this so let's put it above the rollups whenever it is ready again.

@bors p=10

[rustbot]

Some changes occurred in src/tools/opt-dist

cc @Kobzol

[Mark-Simulacrum]

@bors r=albertlarsan68

[bors]

📌 Commit abb1eba has been approved by albertlarsan68

It is now in the queue for this repository.

[bors]

⌛ Testing commit abb1eba with merge f8060d2...

[bors]

☀️ Test successful - checks-actions
Approved by: albertlarsan68
Pushing f8060d2 to master...

[rust-timer]

Finished benchmarking commit (f8060d2): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary 2.4%, secondary 3.8%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	2.4%	[2.4%, 2.4%]	1
Regressions ❌ (secondary)	3.8%	[2.1%, 6.2%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.4%	[2.4%, 2.4%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 769.469s -> 769.587s (0.02%)
Artifact size: 331.90 MiB -> 331.78 MiB (-0.04%)