Rollup of 5 pull requests
Successful merges:
- #70644 (Clean up `ModuleConfig` initialization)
- #70937 (Fix staticlib name for *-pc-windows-gnu targets)
- #70996 (Add or_insert_with_key to Entry of HashMap/BTreeMap)
- #71020 (Store UNICODE_VERSION as a tuple)
- #71021 (Use write!-style syntax for MIR assert terminator)
Failed merges:
r? @ghost
Store UNICODE_VERSION as a tuple
Remove the UnicodeVersion struct containing
major, minor and update fields and replace it with
a 3-tuple containing the version number.
As the value of each field is limited to 255
use u8 to store them.
Add or_insert_with_key to Entry of HashMap/BTreeMap
Going along with `or_insert_with`, `or_insert_with_key` provides the `Entry`'s key to the lambda, avoiding the need to either clone the key or the need to reimplement this body of this method from scratch each time.
This is useful when the initial value for a map entry is derived from the key. For example, the introductory Rust book has an example Cacher struct that takes an expensive-to-compute lambda and then can, given an argument to the lambda, produce either the cached result or execute the lambda.
---
I'm fairly new to Rust, so any optimizations, corrections to types, better names, better documentation, or whatever else would be appreciated. I'd like to thank Arnavion on freenode for helping me to implement a very similar method when I found that `or_insert_with_key` was unavailable.
As a somewhat-related note, this implements https://github.com/rust-lang/rfcs/issues/1202 from 2015, so if this pull request is accepted, that should be closed.
Rollup of 5 pull requests
Successful merges:
- #69573 (tests encoding current behavior for various cases of "binding" to _.)
- #70881 (bootstrap: work around "unused attribute" errors in incremental stdlib rebuilds.)
- #70957 (Normalize MIR locals' types for generator layout computation.)
- #70962 (added machine hooks to track deallocations)
- #70982 (Normalize function signature in function casting check procedure)
Failed merges:
r? @ghost
Remove the UnicodeVersion struct containing
major, minor and update fields and replace it with
a 3-tuple containing the version number.
As the value of each field is limited to 255
use u8 to store them.
tests encoding current behavior for various cases of "binding" to _.
The `_` binding form is special, in that it encodes a "no-op": nothing is actually bound, and thus nothing is moved or borrowed in this scenario. Usually we do the "right" thing in all such cases. The exceptions are explicitly pointed out in this test case, so that we keep track of whether they are eventually fixed.
Cc #53114.
(This does not close the aforementioned issue; it just adds the tests encoding the current behavior, which we hope to eventually fix.)
Normalize function signature in function casting check procedure
Fixes#54094
```rust
trait Zoo {
type X;
}
impl Zoo for u16 {
type X = usize;
}
fn foo(abc: <u16 as Zoo>::X) {}
fn main() {
let x: *const u8 = foo as _;
}
```
Currently a `FnDef` need to be checked if it's able to cast to `FnPtr` before it is actually casted. But the signature of `FnPtr` target's associated types are not normalized:
96d77f0e5f/src/librustc_typeck/check/cast.rs (L536-L553)
However, during the coercion check, the signature of `FnPtr` target's associated types are normalized (The `<u16 as Zoo>::X` turns into `usize`).
96d77f0e5f/src/librustc_typeck/check/coercion.rs (L687-L729)
This inconsistency leads to the error:`Err(Sorts(ExpectedFound { expected: <u16 as Zoo>::X, found: usize }))`.
added machine hooks to track deallocations
This is part of rust-lang/miri#1314 in order to allow miri to show stack traces for on deallocation in order to debug use-after-free bugs
bootstrap: work around "unused attribute" errors in incremental stdlib rebuilds.
This should alleviate #58633 separately from a proper fix.
r? @Mark-Simulacrum
tests encoding current behavior for various cases of "binding" to _.
The `_` binding form is special, in that it encodes a "no-op": nothing is actually bound, and thus nothing is moved or borrowed in this scenario. Usually we do the "right" thing in all such cases. The exceptions are explicitly pointed out in this test case, so that we keep track of whether they are eventually fixed.
Cc #53114.
(This does not close the aforementioned issue; it just adds the tests encoding the current behavior, which we hope to eventually fix.)
rustc_middle: return `LocalDefId` where possible in hir::map module
This changes the return type of the following functions to return a `LocalDefId` instead of a `DefId`:
* opt_local_def_id_from_node_id
* opt_local_def_id
* body_owner_def_id
* local_def_id_from_node_id
* get_parent_id
This is another step in the right direction for #70853
This pull request will be followed by another (substantial one) which changes the return type of `local_def_id` function but this change being more invasive, we might want to wait for #70956 or #70961 (or some other form it) to land first.
Going along with or_insert_with, or_insert_with_key provides the
Entry's key to the lambda, avoiding the need to either clone the
key or the need to reimplement this body of this method from
scratch each time.
This is useful when the initial value for a map entry is derived
from the key. For example, the introductory Rust book has an
example Cacher struct that takes an expensive-to-compute lambda and
then can, given an argument to the lambda, produce either the
cached result or execute the lambda.
Setup the `@rustbot prioritize` command
See rust-lang/triagebot#453
r? @Mark-Simulacrum can you confirm that the `t-compiler/wg-prioritization` stream ID is `227806`?
cc @spastorino
Rearrange BTreeMap::into_iter to match range_mut.
r? @Mark-Simulacrum
I wondered why you catered for the optional root differently in `into_iter` than in `range_mut`.
Use forward traversal for unconditional recursion lint
While reviewing #70822, I noted that #54444 could be solved without requiring the predecessor graph and without allocating a `Vec<Span>` for every basic block. The unconditional recursion lint is not a performance bottleneck however, so I approved #70822 as it was.
Nevertheless, I wanted to try implementing my idea using `TriColorDepthFirstSearch`, which is a DFS that can differentiate between [forward/tree edges and backward ones](https://en.wikipedia.org/wiki/Depth-first_search#Output_of_a_depth-first_search). I found this approach more straightforward than the existing one, so I'm opening this PR to see if it is desirable.
The pass is now just a DFS across the control-flow graph. We ignore false edges and false unwinds, as well as the successors of recursive calls, just like existing pass does. If we see a back-edge (loop) or a terminator that would cause us to yield control-flow back to the caller (`Return`, `Resume`, etc.), we know that the function does not unconditionally recurse.
r? @jonas-schievink
Use `PredicateObligation`s instead of `Predicate`s
Keep more information about trait binding failures. Use more specific spans by pointing at bindings that introduce obligations.
Subset of #69709.
r? @eddyb
Stop explicitly depending on python 2
This PR revises our previous policy of officially only supporting and testing with python 2 in the CI environment to instead test with python 3. It also changes the defaults to python 3 in our various scripts (usually, by way of `python` rather than `python3` to preserve compatibility with systems that do not have a python 3 available).
The effect of this is that we expect all new patches to support python 3 (and will test as such). We explicitly also expect that patches support python 2.7 as well -- and test as such, though only on one builder. This is intended as a temporary, though likely long-lived, measure to preserve compatibility while looking towards the future which is likely to be a python 3 only world. We do not at this point set a timeline for when we'll drop support for python 2.7; it's plausible that this is months or years into the future, depending on how quickly the ecosystem drops support and how painful it is for us to maintain that support over time.
Closes#65063 (as far as I can tell; please file explicit and separate issues or PRs if not).
The `_` binding form is special, in that it encodes a "no-op": nothing is
actually bound, and thus nothing is moved or borrowed in this scenario. Usually
we do the "right" thing in all such cases. The exceptions are explicitly pointed
out in this test case, so that we keep track of whether they are eventually
fixed.
