Rollup of 4 pull requests #98161
Merged
Rollup of 4 pull requests #98161
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
Updated the HashMap's documentation to include two references to add_modify. The first is when the `Entry` API is mentioned at the beginning. I was hesitant to change the "attack" example (although I believe that it is perfect example of where `add_modify` should be used) because both uses work equally, but one is more idiomatic (`add_modify`). The second is with the `entry` function that is used for the `Entry` API. The code example was a perfect use for `add_modify`, which is why it was changed to reflect that.
Updated the btree's documentation to include two references to add_modify. The first is when the `Entry` API is mentioned at the beginning. With the same reasoning as HashMap's documentation, I thought it would best to keep `attack`, but show the `mana` example. The second is with the `entry` function that is used for the `Entry` API. The code example was a perfect use for `add_modify`, which is why it was changed to reflect that.
Incorrectly wrote "1" twice when writing test.
As was discovered in rust-lang#93628 (comment) , adding #[cfg(bootstrap)] to a rust-internal proc macro crate would yield an unexpected cfg name error, at least on later stages wher the bootstrap cfg arg wasn't set. rustc already passes arguments to mark bootstrap as expected, however the means of delivery through the RUSTFLAGS env var is unable to reach proc macro crates, as described in the issue linked in the code this commit touches. This wouldn't be an issue for cfg args that get passed through RUSTFLAGS, as they would never become *active* either, so any usage of one of these flags in a proc macro's code would legitimately yield a lint warning. But since dc30258, rust takes extra measures to pass --cfg=bootstrap even in proc macros, by passing it via the wrapper. Thus, we need to send the flags to mark bootstrap as expected also from the wrapper, so that #[cfg(bootstrap)] also works from proc macros. I want to thank Urgau and jplatte for helping me find the cause of this. ❤️
…-warn, r=wesleywiser,flip1995 Support lint expectations for `--force-warn` lints (RFC 2383) Rustc has a `--force-warn` flag, which overrides lint level attributes and forces the diagnostics to always be warn. This means, that for lint expectations, the diagnostic can't be suppressed as usual. This also means that the expectation would not be fulfilled, even if a lint had been triggered in the expected scope. This PR now also tracks the expectation ID in the `ForceWarn` level. I've also made some minor adjustments, to possibly catch more bugs and make the whole implementation more robust. This will probably conflict with rust-lang#97718. That PR should ideally be reviewed and merged first. The conflict itself will be trivial to fix. --- r? `@wesleywiser` cc: `@flip1995` since you've helped with the initial review and also discussed this topic with me. 🙃 Follow-up of: rust-lang#87835 Issue: rust-lang#85549 Yeah, and that's it.
…ylan-DPC Entry and_modify doc This PR modifies the documentation for [HashMap](https://doc.rust-lang.org/std/collections/struct.HashMap.html#) and [BTreeMap](https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#) by introducing examples for `and_modify`. `and_modify` is a function that tends to give more idiomatic rust code when dealing with these data structures -- yet it lacked examples and was hidden away. This PR adds that and addresses rust-lang#98122. I've made some choices which I tried to explain in my commits. This is my first time contributing to rust, so hopefully, I made the right choices.
…-natvis, r=wesleywiser
debuginfo: Fix NatVis for Rc and Arc with unsized pointees.
Currently, the NatVis for `Rc<T>` and `Arc<T>` does not support unsized `T`. For both `Rc<T>` and `Rc<dyn SomeTrait>` the visualizers fail:
```txt
[Reference count] : -> must be used on pointers and . on structures
[Weak reference count] : -> must be used on pointers and . on structures
```
This PR fixes the visualizers. For slices we can even give show the elements, so one now gets something like:
```txt
slice_rc : { len=3 }
[Length] : 3
[Reference count] : 41
[Weak reference count] : 2
[0] : 1
[1] : 2
[2] : 3
```
r? `@wesleywiser`
…mulacrum Make #[cfg(bootstrap)] not error in proc macros on later stages As was discovered in rust-lang#93628 (comment), adding #[cfg(bootstrap)] to a rust-internal proc macro crate would yield an unexpected cfg name error, at least on later stages wher the bootstrap cfg arg wasn't set. rustc already passes arguments to mark bootstrap as expected, however the means of delivery through the RUSTFLAGS env var is unable to reach proc macro crates, as described in the issue linked in the code this commit touches. This wouldn't be an issue for cfg args that get passed through RUSTFLAGS, as they would never become *active* either, so any usage of one of these flags in a proc macro's code would legitimately yield a lint warning. But since dc30258, rust takes extra measures to pass --cfg=bootstrap even in proc macros, by passing it via the wrapper. Thus, we need to send the flags to mark bootstrap as expected also from the wrapper, so that #[cfg(bootstrap)] also works from proc macros. I want to thank `Urgau` and `jplatte` for helping me find the cause of this. ❤️
rustbot
added
T-compiler
|
@bors r+ rollup=never p=4 |
|
📌 Commit 97a7a3c has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
Merged
|
Finished benchmarking commit (d40f24e): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
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:
--force-warnlints (RFC 2383) #97757 (Support lint expectations for--force-warnlints (RFC 2383))Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup