Rollup of 5 pull requests
Successful merges:
- #71311 (On `FnDef` type annotation suggestion, use fn-pointer output)
- #71488 (normalize field projection ty to fix broken MIR issue)
- #71489 (Fix off by one in treat err as bug)
- #71585 (remove obsolete comment)
- #71634 (Revert #71372 ("Fix #! (shebang) stripping account space issue").)
Failed merges:
r? @ghost
Revert #71372 ("Fix #! (shebang) stripping account space issue").
While #71372 fixed some of the problems `#!`-stripping had, it introduced others:
* inefficient implementation (`.chars().filter(...).collect()` on the entire input file)
* this also means the length returned isn't always correct, leading to e.g. #71471
* it ignores whitespace anywhere, stripping ` # ! ...` which isn't a valid shebang
* the definition of "whitespace" it uses includes newlines, which means even `\n#\n!\n...` is stripped as a shebang (and anything matching the regex `\s*#\s*!\s*`, and not followed by `[`, really)
* it's backward-incompatible but didn't go through Crater
Now, #71487 is already open and will solve all of these issues. But for running Crater, and just in case #71487 takes a bit longer, I decided it's safer to just revert #71372.
This will also make #71372's diff clearer, as it will start again from the original whitespace-unaware version.
r? @petrochenkov
smoke-test for async fn with mir-opt-level=0
MIR opt levels heavily influence which MIR transformations run, and we barely test non-default opt levels. I am particularly worried about `async fn` lowering and how it might (not) work when the set of preceding MIR passes changes -- see https://github.com/rust-lang/rust/pull/70073.
This adds some basic smoke testing, where at least a few `async fn` `run-pass` test are ensured to also work with mir-opt-level=0.
Minimize parameter of coerce_borrowed_pointer()
Change last parameter of `coerce_borrowed_pointer()` from `TypeAndMut` to `Mutability` (similar to `coerce_unsafe_ptr()`), since the `TypeAndMut::ty` is never used directly in this function.
Add Read/Write::can_read/write_vectored
When working with an arbitrary reader or writer, code that uses vectored
operations may end up being slower than code that copies into a single
buffer when the underlying reader or writer doesn't actually support
vectored operations. These new methods allow you to ask the reader or
witer up front if vectored operations are efficiently supported.
Currently, you have to use some heuristics to guess by e.g. checking if
the read or write only accessed the first buffer. Hyper is one concrete
example of a library that has to do this dynamically:
0eaf304644/src/proto/h1/io.rs (L582-L594)
Don't run various MIR optimizations at mir-opt-level=0
Add missing checks for mir-opt-level to non-essential MIR passes.
I verified that this can still bootstrap even with these passes disabled.
r? @oli-obk cc @RalfJung
