Move various checks to typeck so them failing causes the typeck result to get tainted
Fixes#69487fixes#79047
cc `@RalfJung` this gets rid of the `Transmute` invalid program error variant
Fix multiline attributes processing in doctest
Fixes#97440.
It seems like the call to `check_if_attr_is_complete` is not provided with the correct argument: the pending attribute should be passed, while the current line is actually being passed. This causes any attribute with more than 2 lines to fail and produces ICE when running through doctest.
libcore: Add `iter::from_generator` which is like `iter::from_fn`, but for coroutines instead of functions
An equally useful little helper.
I didn't follow any of the async-wg work, so I don't know why something like this wasn't added before.
Updates to browser-ui-test
I took the commits from #97317. Since the ubuntu 22.04 version, you either need to use `--no-sandbox` or use another binary to run the GUI tests. I couldn't find out why the chromium used by `browser-ui-test` isn't working anymore on this ubuntu version.
r? `@notriddle`
Add section on common message styles for Result::expect
Based on a question from https://github.com/rust-lang/project-error-handling/issues/50#issuecomment-1092339937
~~One thing I haven't decided on yet, should I duplicate this section on `Option::expect`, link to this section, or move it somewhere else and link to that location from both docs?~~: I ended up moving the section to `std::error` and referencing it from both `Result::expect` and `Option::expect`'s docs.
I think this section, when combined with the similar update I made on [`std::panic!`](https://doc.rust-lang.org/nightly/std/macro.panic.html#when-to-use-panic-vs-result) implies that we should possibly more aggressively encourage and support the "expect as precondition" style described in this section. The consensus among the libs team seems to be that panic should be used for bugs, not expected potential failure modes. The "expect as error message" style seems to align better with the panic for unrecoverable errors style where they're seen as normal errors where the only difference is a desire to kill the current execution unit (aka erlang style error handling). I'm wondering if we should be providing a panic hook similar to `human-panic` or more strongly recommending the "expect as precondition" style of expect message.
improve case conversion happy path
Someone shared the source code for [Go's string case conversion](19156a5474/src/strings/strings.go (L558-L616)).
It features a hot path for ascii-only strings (although I assume for reasons specific to go, they've opted for a read safe hot loop).
I've borrowed these ideas and also kept our existing code to provide a fast path + seamless utf-8 correct path fallback.
(Naive) Benchmarks can be found here https://github.com/conradludgate/case-conv
For the cases where non-ascii is found near the start, the performance of this algorithm does fall back to original speeds and has not had any measurable speed loss
omit `record_accesses` function when collecting `MonoItem`s
This PR fixes the FIXME in the impl of `record_accesses` function.
[Edit] We can call `instantiation_mode` when push the `MonoItem` into `neighbors`. This avoids extra local variables `accesses: SmallVec<[_; 128]>`
Only allow `compiletest` to use `feature(test)`, not any other feature
Using language features occasionally causes issues when using nightly to bootstrap, rather than beta.
See #59264 for additional context.
`imported_source_files` adjusts lots of file positions, and then calls
`new_imported_source_file`, which then adjust them all again. This
commit combines the two adjustments into one, for a small perf win.
