Rollup of 6 pull requests #68907
Merged
Rollup of 6 pull requests #68907
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
...and unify it with `()` for now
This makes some error messages ungreat, but those seem to be preexisting bugs that also apply to closures / return position `impl Trait` in general.
This changes `Yield` from `as_rvalue` to `into` lowering, which could have a possible performance impact. I could imagine special-casing some resume types here to use a simpler lowering for them, but it's unclear if that makes sense at this stage.
The resume arg is passed as argument `_2` and needs to be moved to the `Yield`s target `Place`
Instead of "closure is expected to take 0 arguments" we now get the expected type mismatch error.
I suppose we could also just put `tcx.mk_unit()` here, but this works too
It does not have unwinding support
Now that compile_fail attempts a full build rather than --emit=metadata, these errors should be caught by compile_fail and do not need to be ignored.
In the docs for option.rs and result.rs, it is noted for all *_or() functions that they are eagerly evaluated, except for the map_or() function. This commit adds this missing documentation to the two files.
… r=petrochenkov Rename -Zexternal-macro-backtrace to -Zmacro-backtrace and clean up implementation. This is my attempt at dealing with rust-lang#66364 (comment), although I'm not sure it's the least disruptive one. The behavior of `-Zexternal-macro-backtrace` was already to enable full macro backtraces for *all* macros, the only part of it that was specific to cross-crate macros was showing this when *not used*: ``` note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info) ``` After this PR: * the flag is renamed to `-Zmacro-backtrace` * do we need to have a deprecation period? cc @rust-lang/compiler * the message informing you about the flag is always shown when an expansion of a bang macro/attribute/derive is involved, not just cross-crate ones * this accounts for most of the changes in tests * we could perhaps only show it for the bang macro case? feels odd for derives * `fix_multispans_in_std_macros` is split into `fix_multispans_in_extern_macros` and `render_multispans_macro_backtrace` * this roughly reverts the non-behavioral parts of rust-lang#46605, which combined the two functionalities * not sure where the old `std_macros` name came from, perhaps the `<std macros>` synthetic "file"? even then, odd that `std` specifically was mentioned * `render_multispan_macro_backtrace`, by default (i.e. without `-Zmacro-backtrace`), hides the `in this macro invocation` label specifically to avoid redundancy in the diagnostic * that is, showing the macro use site is only useful when the diagnostic is inside the macro definition and the user can't otherwise tell which use site it applies to, not when the diagnostic is at/inside the use site already (which would make the label redundant) * before, it was only checking for the situation in which a cross-crate macro *definition* span would be replaced with the invocation span, which both made the connection to redundancy unobvious, and didn't help with other redundancy (e.g. when the diagnostic was pointing to an argument inside the macro invocation) * this accounts for the remaining test changes, which I've first noticed in rust-lang#66364 (comment) but only later understood as part of this PR (hence the "redundancy" descriptions) This PR is not needed for rust-lang#66364, but it would help, as after this PR there's only one `.span_to_filename(...).is_macros()` check (i.e. for `<... macros>` synthetic "files") left in `rustc_errors`, and it's much more self-contained. r? @petrochenkov
…guments, r=Zoxc Generator Resume Arguments cc rust-lang#43122 and rust-lang#56974 Blockers: * [x] Fix miscompilation when resume argument is live across a yield point (rust-lang#68524 (comment)) * [x] Fix 10% compile time regression in `await-call-tree` benchmarks (rust-lang#68524 (comment)) * [x] Fix remaining 1-3% regression (rust-lang#68524 (comment)) - resolved (rust-lang#68524 (comment)) * [x] Make dropck rules account for resume arguments (rust-lang#68524 (comment)) Follow-up work: * Change async/await desugaring to make use of this feature * Rewrite [`box_region.rs`](https://github.com/rust-lang/rust/blob/3d8778d767f0dde6fe2bc9459f21ead8e124d8cb/src/librustc_data_structures/box_region.rs) to use resume arguments (this shows up in profiles too)
…JohnTitor implement proper linkchecker hardening r? @JohnTitor This implements proper linkcheck filtering... we might need to fiddle with a bit to adjust what is or isn't filtered, but this seems to work reasonable locally.
Mark fn map_or() as eagerly evaluated. In the docs for option.rs and result.rs, it is noted for all *_or() functions that they are eagerly evaluated, except for the map_or() function. This commit adds this missing documentation to the two files. Closes rust-lang#68866
…petrochenkov error code examples: replace some more ignore with compile_fail Now that rust-lang#68664 has been merged and `compile_fail` attempts a full build rather than `--emit=metadata`, these errors should be caught by `compile_fail` and do not need to be ignored.
Update E0565 examples Fixes rust-lang#68892 r? @GuillaumeGomez
|
@bors r+ rollup=never p=6 |
|
📌 Commit 7ef5b89 has been approved by |
bors
added
the
S-waiting-on-bors
|
Seems no pending PRs |
bors
added a commit
that referenced
this pull request
Feb 7, 2020
Rollup of 6 pull requests Successful merges: - #67359 (Rename -Zexternal-macro-backtrace to -Zmacro-backtrace and clean up implementation.) - #68524 (Generator Resume Arguments) - #68791 (implement proper linkchecker hardening) - #68886 (Mark fn map_or() as eagerly evaluated.) - #68888 (error code examples: replace some more ignore with compile_fail) - #68894 (Update E0565 examples) Failed merges: r? @ghost
|
☀️ Test successful - checks-azure |
This was referenced Feb 7, 2020
|
📣 Toolstate changed by #68907! Tested on commit f8fd462. 💔 rls on windows: test-pass → build-fail (cc @Xanewok, @rust-lang/infra). |
rust-highfive
added a commit
to rust-lang-nursery/rust-toolstate
that referenced
this pull request
Feb 7, 2020
Tested on commit rust-lang/rust@f8fd462. Direct link to PR: <rust-lang/rust#68907> 💔 rls on windows: test-pass → build-fail (cc @Xanewok, @rust-lang/infra). 💔 rls on linux: test-pass → build-fail (cc @Xanewok, @rust-lang/infra). 💔 rustfmt on windows: test-pass → build-fail (cc @topecongiro, @rust-lang/infra). 💔 rustfmt on linux: test-pass → build-fail (cc @topecongiro, @rust-lang/infra). 🎉 rustc-guide on linux: test-fail → test-pass (cc @JohnTitor @amanjeev @spastorino @mark-i-m, @rust-lang/infra).
This was referenced Feb 7, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
Failed merges:
r? @ghost