Rollup of 11 pull requests

src/ci/cpu-usage-over-time.py

@@ -30,23 +30,8 @@
 # the second column is always zero.
 #
 # Once you've downloaded a file there's various ways to plot it and visualize
-# it. For command line usage you can use a script like so:
-#
-#      set timefmt '%Y-%m-%dT%H:%M:%S'
-#      set xdata time
-#      set ylabel "Idle CPU %"
-#      set xlabel "Time"
-#      set datafile sep ','
-#      set term png
-#      set output "printme.png"
-#      set grid
-#      builder = "i686-apple"
-#      plot "cpu-".builder.".csv" using 1:2 with lines title builder
-#
-# Executed as `gnuplot < ./foo.plot` it will generate a graph called
-# `printme.png` which you can then open up. If you know how to improve this
-# script or the viewing process that would be much appreciated :) (or even if
-# you know how to automate it!)
+# it. For command line usage you use the `src/etc/cpu-usage-over-time-plot.sh`
+# script in this repository.
 
 import datetime
 import sys

src/doc/unstable-book/src/language-features/plugin.md

@@ -132,7 +132,7 @@ The advantages over a simple `fn(&str) -> u32` are:
 In addition to procedural macros, you can define new
 [`derive`](../../reference/attributes/derive.md)-like attributes and other kinds
 of extensions.  See `Registry::register_syntax_extension` and the
-`SyntaxExtension` enum.  For a more involved macro example, see
+`SyntaxExtension` struct.  For a more involved macro example, see
 [`regex_macros`](https://github.com/rust-lang/regex/blob/master/regex_macros/src/lib.rs).
 
 

src/etc/cpu-usage-over-time-plot.sh

@@ -0,0 +1,49 @@
+#!/bin/bash
+
+# A small script to help visualizing CPU usage over time data collected on CI
+# using `gnuplot`.
+#
+# This script is expected to be called with two arguments. The first is the full
+# commit SHA of the build you're interested in, and the second is the name of
+# the builder. For example:
+#
+#  ./src/etc/cpu-usage-over-time-plot.sh e699ea096fcc2fc9ce8e8bcf884e11496a31cc9f i686-mingw-1
+#
+# That will generate `$builder.png` in the current directory which you can open
+# up to see a hopefully pretty graph.
+#
+# Improvements to this script are greatly appreciated!
+
+set -ex
+
+bucket=rust-lang-ci-evalazure
+commit=$1
+builder=$2
+
+curl -O https://$bucket.s3.amazonaws.com/rustc-builds/$commit/cpu-$builder.csv
+
+gnuplot <<-EOF
+reset
+set timefmt '%Y-%m-%dT%H:%M:%S'
+set xdata time
+set ylabel "CPU Usage %"
+set xlabel "Time"
+set datafile sep ','
+set term png size 3000,1000
+set output "$builder.png"
+set grid
+
+f(x) = mean_y
+fit f(x) 'cpu-$builder.csv' using 1:(100-\$2) via mean_y
+
+set label 1 gprintf("Average = %g%%", mean_y) center font ",18"
+set label 1 at graph 0.50, 0.25
+set xtics rotate by 45 offset -2,-2.4 300
+set ytics 10
+set boxwidth 0.5
+
+plot \\
+   mean_y with lines linetype 1 linecolor rgb "#ff0000" title "average", \\
+   "cpu-$builder.csv" using 1:(100-\$2) with points pointtype 7 pointsize 0.4 title "$builder", \\
+   "" using 1:(100-\$2) smooth bezier linewidth 3 title "bezier"
+EOF

src/libcore/lib.rs

@@ -100,6 +100,7 @@
 #![feature(staged_api)]
 #![feature(std_internals)]
 #![feature(stmt_expr_attributes)]
+#![cfg_attr(not(bootstrap), feature(transparent_unions))]
 #![feature(unboxed_closures)]
 #![feature(unsized_locals)]
 #![feature(untagged_unions)]

src/libcore/mem/maybe_uninit.rs

@@ -172,7 +172,7 @@ use crate::mem::ManuallyDrop;
 ///
 /// # Layout
 ///
-/// `MaybeUninit<T>` is guaranteed to have the same size and alignment as `T`:
+/// `MaybeUninit<T>` is guaranteed to have the same size, alignment, and ABI as `T`:
 ///
 /// ```rust
 /// use std::mem::{MaybeUninit, size_of, align_of};
@@ -191,9 +191,23 @@ use crate::mem::ManuallyDrop;
 /// assert_eq!(size_of::<Option<bool>>(), 1);
 /// assert_eq!(size_of::<Option<MaybeUninit<bool>>>(), 2);
 /// ```
+///
+/// If `T` is FFI-safe, then so is `MaybeUninit<T>`.
+///
+/// While `MaybeUninit` is `#[repr(transparent)]` (indicating it guarantees the same size,
+/// alignment, and ABI as `T`), this does *not* change any of the previous caveats. `Option<T>` and
+/// `Option<MaybeUninit<T>>` may still have different sizes, and types containing a field of type
+/// `T` may be laid out (and sized) differently than if that field were `MaybeUninit<T>`.
+/// `MaybeUninit` is a union type, and `#[repr(transparent)]` on unions is unstable (see [the
+/// tracking issue](https://github.com/rust-lang/rust/issues/60405)). Over time, the exact
+/// guarantees of `#[repr(transparent)]` on unions may evolve, and `MaybeUninit` may or may not
+/// remain `#[repr(transparent)]`. That said, `MaybeUninit<T>` will *always* guarantee that it has
+/// the same size, alignment, and ABI as `T`; it's just that the way `MaybeUninit` implements that
+/// guarantee may evolve.
 #[allow(missing_debug_implementations)]
 #[stable(feature = "maybe_uninit", since = "1.36.0")]
 #[derive(Copy)]
+#[cfg_attr(not(bootstrap), repr(transparent))]
 pub union MaybeUninit<T> {
     uninit: (),
     value: ManuallyDrop<T>,

src/librustc/cfg/construct.rs

@@ -330,7 +330,7 @@ impl<'a, 'tcx> CFGBuilder<'a, 'tcx> {
             hir::ExprKind::DropTemps(ref e) |
             hir::ExprKind::Unary(_, ref e) |
             hir::ExprKind::Field(ref e, _) |
-            hir::ExprKind::Yield(ref e) |
+            hir::ExprKind::Yield(ref e, _) |
             hir::ExprKind::Repeat(ref e, _) => {
                 self.straightline(expr, pred, Some(&**e).into_iter())
             }

src/librustc/hir/intravisit.rs

@@ -1089,7 +1089,7 @@ pub fn walk_expr<'v, V: Visitor<'v>>(visitor: &mut V, expression: &'v Expr) {
                 visitor.visit_expr(expr)
             }
         }
-        ExprKind::Yield(ref subexpression) => {
+        ExprKind::Yield(ref subexpression, _) => {
             visitor.visit_expr(subexpression);
         }
         ExprKind::Lit(_) | ExprKind::Err => {}