Rollup of 6 pull requests #99590
Closed
Rollup of 6 pull requests #99590
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
To generate a function coverage we need at least one coverage counter, so a coverage from unreachable blocks is retained only when some live counters remain. The previous implementation incorrectly retained unreachable coverage, because it didn't account for the fact that those live counters can belong to another function due to inlining.
This renames the methods to use the `cast_` prefix instead of `as_` to make it more readable and avoid confusion with `<*mut T>::as_mut()` which is `unsafe` and returns a reference. See rust-lang#92675
…cast, r=scottmcm
Rename `<*{mut,const} T>::as_{const,mut}` to `cast_`
This renames the methods to use the `cast_` prefix instead of `as_` to
make it more readable and avoid confusion with `<*mut T>::as_mut()`
which is `unsafe` and returns a reference.
Sorry, didn't notice ACP process exists, opened rust-lang/libs-team#51
See rust-lang#92675
…leywiser Fix unreachable coverage generation for inlined functions To generate a function coverage we need at least one coverage counter, so a coverage from unreachable blocks is retained only when some live counters remain. The previous implementation incorrectly retained unreachable coverage, because it didn't account for the fact that those live counters can belong to another function due to inlining. Fixes rust-lang#98833.
… r=notriddle Group CSS font rule Another CSS cleanup I came by when working on something else. r? `@notriddle`
…-item, r=lcnr Do not resolve associated const when there is no provided value Fixes rust-lang#98629, since now we just delay a bug when we're not able to evaluate a const item due to the value not actually being provided by anything. This means compilation proceeds forward to where the "missing item in impl" error is emitted. ---- The root issue here is that when we're looking for the defining `LeafDef` in `resolve_associated_item`, we end up getting the trait's AssocItem instead of the impl's AssocItem (which does not exist). This resolution "succeeds" even if the trait's item has no default value, and then since this item has no value to evaluate, it turns into a const eval error. This root issue becomes problematic (as in rust-lang#98629) when this const eval error happens in wfcheck (for example, due to normalizing the param-env of something that references this const). Since this happens sooner than the check that an impl actually provides all of the items that a trait requires (which happens during later typecheck), we end up aborting compilation early with only this un-informative message. I'm not exactly sure _why_ this bug arises due to rust-lang#96591 -- perhaps valtrees are evaluated more eagerly than in the old system? r? `@oli-obk` or `@lcnr` since y'all are familiar with const eval and reviewed rust-lang#96591, though feel free to reassign. This is a regression from stable to beta, so I would be open to considering this for beta backport. It seems correct to me, especially given the improvements in the other UI tests this PR touches, but may have some side-effects that I'm unaware of...?
…-suggestions, r=fee1-dead Improve suggestions for returning binding Fixes rust-lang#99525 Also reworks the cause codes for match and if a bit, I think cleaning them up in a positive way. We no longer need to call `could_remove_semicolon` in successful code, which might save a few cycles?
…lett Add same warning to Result::expect as Result::unwrap I was reading a recent blog post by Jimmy Hartzell and [he noted](https://www.thecodedmessage.com/posts/2022-07-14-programming-unwrap/#context): > I will however note that the documentation of `unwrap` comes with [a warning not to use it](https://doc.rust-lang.org/std/result/enum.Result.html#method.unwrap). The warning is framed in terms of the fact that `unwrap` may panic, but the [documentation of `expect`](https://doc.rust-lang.org/std/result/enum.Result.html#method.expect), where this is equally true, does not come with such a warning. It _is_ equally true. Let's add the same warning to `expect`. This PR is a copy-and-paste of the warning text from the docstring for `unwrap`.
rustbot
added
T-compiler
|
@bors r+ rollup=never p=5 |
bors
added
the
S-waiting-on-bors
|
The job Click to see the possible cause of the failure (guessed by this bot) |
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:
<*{mut,const} T>::as_{const,mut}tocast_#98174 (Rename<*{mut,const} T>::as_{const,mut}tocast_)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup