-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 7 pull requests #68956
Rollup of 7 pull requests #68956
Conversation
…p_first, pop_last
It's tautological, and Rust-specific Jargon. This changes various Option/Result methods to consistently describe unwrapping behavior using the words "return", "contain", "consume". It also renames the closure argument of `Return::unwrap_or_else` to `default` to be consistent with `Option`.
This reduces the number of `associated_item` queries done here.
Quickly skip impls that do not define any items with the same name
Implement proper C ABI lowering for RISC-V This is necessary for full RISC-V psABI compliance when passing argument across C FFI boundary. cc @lenary
…r=KodrAus Fix and test implementation of BTreeMap's first/last_entry, pop_first/last Properly implement and test `first_entry` & `last_entry` to fix problem report rust-lang#68829
…agisa rustc_codegen_llvm: always set AlwaysPreserve on all debuginfo variables Making this depend on the optimization level appears to have been a copy-paste mistake (other LLVM functions called in this module also take a `bool` argument, but there it means something unrelated). Also see rust-lang#8855 (comment). I don't believe we have any reason to let LLVM omit user variables from DWARF, and we were already setting this to `true` when LLVM *could* optimize them away, so this PR should have no effect anyway. r? @michaelwoerister or @nagisa cc @rkruppe @nikomatsakis
Make the `type_of` return a generic type for generators Fixes rust-lang#67651. r? @nikomatsakis
…=petrochenkov Speed up the inherent impl overlap check This gives a ~7% improvement in compile times for the stm32f0(x2) crate. Also addresses @eddyb's comment in rust-lang#68837 (comment).
Pretty-print generic params and where clauses on associated types closes rust-lang#67509
Don't use the word "unwrap" to describe "unwrap" methods It's tautological, and "unwrap" is essentially Rust-specific jargon. I was teaching a newbie some Rust, and doing the usual hand-waving about error handling using unwrap. They asked what 'unwrap' means. I said look it up in the docs. The docs read (paraphrased) "unwrap unwraps". I was embarrassed. This changes all the Option/Result functions with unwrapping behavior to use a variation on a single description: > "Returns the contained `Some/Ok` value [or ...]." It also renames the closure of `Result::unwrap_or_else` to `default` for consistency with `Option`, and perhaps makes a few other small tweaks. Previous: rust-lang#68849
@bors r+ p=7 rollup=never |
📌 Commit 57212d8 has been approved by |
⌛ Testing commit 57212d8 with merge b610afcea8d002b3c5093b509dbceda53d8400cc... |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
💔 Test failed - checks-azure |
Successful merges:
type_of
return a generic type for generators #68884 (Make thetype_of
return a generic type for generators)Failed merges:
r? @ghost