Auto merge of #76176 - marmeladema:fix-closure-path-printing, r=eddyb
Move from {{closure}}#0 syntax to {closure#0} for (def) path components
Part of #70334
I followed the approach described by `@eddyb` and introduced a `DefPathDataName` enum.
To preserve compatibility, in various places, I had to rely on formatting manually by calling `format!("{{{{{}}}}}", namespace)`.
My questions are:
* Do we want to convert for places to use the new naming scheme? Or shall I re-add `DefPathData::as_symbol` but renamed as `DefPathData::as_legacy_symbol` to avoid manually allocating the legacy symbols?
* Do we want to `impl Display for DisambiguatedDefPathData` to avoid manually calling `write!(s, "{{{}#{}}}", namespace, component.disambiguator)`?
* We might also want to improve naming for `DefPathDataName` and `DefPathData::get_name`
Auto merge of #77198 - jonas-schievink:rollup-i59i41h, r=jonas-schievink
Rollup of 15 pull requests
Successful merges:
- #76932 (Relax promises about condition variable.)
- #76973 (Unstably allow assume intrinsic in const contexts)
- #77005 (BtreeMap: refactoring around edges)
- #77066 (Fix dest prop miscompilation around references)
- #77073 (dead_code: look at trait impls even if they don't contain items)
- #77086 (Include libunwind in the rust-src component.)
- #77097 (Make [].as_[mut_]ptr_range() (unstably) const.)
- #77106 (clarify that `changelog-seen = 1` goes to the beginning of config.toml)
- #77120 (Add `--keep-stage-std` to `x.py` for keeping only standard library artifacts)
- #77126 (Invalidate local LLVM cache less often)
- #77146 (Install std for non-host targets)
- #77155 (remove enum name from ImplSource variants)
- #77176 (Removing erroneous semicolon in transmute documentation)
- #77183 (Allow multiple allow_internal_unstable attributes)
- #77189 (Remove extra space from vec drawing)
Matthew Jasper [Fri, 25 Sep 2020 18:48:24 +0000 (19:48 +0100)]
Rename Iterator::get_unchecked
It's possible for method resolution to pick this method over a lower
priority stable method, causing compilation errors. Since this method
is permanently unstable, give it a name that is very unlikely to be used
in user code.
Jonas Schievink [Fri, 25 Sep 2020 17:42:46 +0000 (19:42 +0200)]
Rollup merge of #77146 - Mark-Simulacrum:xpyinstall, r=alexcrichton
Install std for non-host targets
It seems reasonable that when configuring various targets you'd expect all of them to get std installed, even if you're not building compiler toolchains for each of those.
Jonas Schievink [Fri, 25 Sep 2020 17:42:44 +0000 (19:42 +0200)]
Rollup merge of #77126 - Mark-Simulacrum:llvm-less-often, r=alexcrichton
Invalidate local LLVM cache less often
This avoids a download of LLVM after every rebase. The downside to this is that if we land some patch affecting LLVM built in CI that breaks this option, but that PR does not update the LLVM submodule, we'll likely not notice until the next update -- but this seems unlikely to happen in practice and I am not personally worried about it.
Jonas Schievink [Fri, 25 Sep 2020 17:42:43 +0000 (19:42 +0200)]
Rollup merge of #77120 - ecstatic-morse:keep-stage-std, r=Mark-Simulacrum
Add `--keep-stage-std` to `x.py` for keeping only standard library artifacts
Unlike `--keep-stage 0`, `--keep-stage-std 0` will allow the stage 0 compiler artifacts (i.e., stage1/bin/rustc) to be rebuilt if it has changed. This allows contributors to iterate on later stages of the compiler in tandem with the standard library without needing to to rebuild the entire compiler. I often run into this when working on const-checking, since I may need to add a feature gate or make a small tweak to the standard library.
Jonas Schievink [Fri, 25 Sep 2020 17:42:39 +0000 (19:42 +0200)]
Rollup merge of #77097 - fusion-engineering-forks:slice-ptr-range-const-fn, r=oli-obk
Make [].as_[mut_]ptr_range() (unstably) const.
Gated behind `const_ptr_offset`, as suggested by https://github.com/rust-lang/rust/issues/65807#issuecomment-697229404
This also marks `[].as_mut_ptr()` as const, because it's used by `as_mut_ptr_range`. I gated it behind the same feature, because I figured it's not worth adding a separate tracking issue for const `as_mut_ptr`.
Jonas Schievink [Fri, 25 Sep 2020 17:42:37 +0000 (19:42 +0200)]
Rollup merge of #77086 - ehuss:src-libunwind, r=Mark-Simulacrum
Include libunwind in the rust-src component.
Some targets, such as musl, need the libunwind source to build the unwind crate (referenced [here](https://github.com/rust-lang/rust/blob/0da58007451a154da2480160429e1604a1f5f0ec/library/unwind/build.rs#L142)).
Jonas Schievink [Fri, 25 Sep 2020 17:42:29 +0000 (19:42 +0200)]
Rollup merge of #76973 - lzutao:unstably-const-assume, r=oli-obk
Unstably allow assume intrinsic in const contexts
Not sure much about this usage because there are concerns
about [blocking optimization][1] and [slowing down LLVM][2] when using `assme` intrinsic
in inline functions.
But since Oli suggested in https://github.com/rust-lang/rust/issues/76960#issuecomment-695772221,
here we are.
Jonas Schievink [Fri, 25 Sep 2020 17:42:28 +0000 (19:42 +0200)]
Rollup merge of #76932 - fusion-engineering-forks:condvar-promise, r=sfackler
Relax promises about condition variable.
For quite a while now, there have been plans to at some point use parking_lot or some other more efficient implementation of mutexes and condition variables. Right now, Mutex and CondVar both Box the 'real' mutex/condvar inside, to give it a stable address. This was done because implementations like pthread and Windows critical sections may not be moved. More efficient implementations based on futexes, WaitOnAddress, Windows SRW locks, parking_lot, etc. may be moved (while not borrowed), so wouldn't need boxing.
However, not boxing them (which would be great goal to achieve), breaks a promise std currently makes about CondVar. CondVar promises to panic when used with different mutexes, to ensure consistent behaviour on all platforms. To this check, a mutex is considered 'the same' if the address of the 'real mutex' in the Box is the same. This address doesn't change when moving a `std::mutex::Mutex` object, effectively giving it an identity that survives moves of the Mutex object. If we ever switch to a non-boxed version, they no longer carry such an identity, and this check can no longer be made.
Four options:
1. Always box mutexes.
2. Add a `MutexId` similar to `ThreadId`. Making mutexes bigger, and making it hard to ever have a `const fn new` for them.
3. Making the requirement of CondVar stricter: panic if the Mutex object itself moved.
4. Making the promise of CondVar weaker: don't promise to panic.
1, 2, and 3 seem like bad options. This PR updates the documentation for 4.
Auto merge of #73453 - erikdesjardins:tuplayout, r=eddyb
Ignore ZST offsets when deciding whether to use Scalar/ScalarPair layout
This is important because Scalar/ScalarPair layout previously would not be used if any ZST had nonzero offset.
For example, before this change, only `((), u128)` would be laid out like `u128`, not `(u128, ())`.
Auto merge of #76844 - simonvandel:fix-76803, r=wesleywiser
Fix #76803 miscompilation
Fixes #76803
Seems like it was an oversight that the discriminant value being set was not compared to the target value from the SwitchInt, as a comment says this is a requirement for the optimization to be sound.
r? `@wesleywiser` since you are probably familiar with the optimization and made #76837 to workaround the bug
Auto merge of #77172 - jonas-schievink:rollup-a041rou, r=jonas-schievink
Rollup of 15 pull requests
Successful merges:
- #75438 (Use adaptive SVG favicon for rustdoc like other rust sites)
- #76304 (Make delegation methods of `std::net::IpAddr` unstably const)
- #76724 (Allow a unique name to be assigned to dataflow graphviz output)
- #76978 (Documented From impls in std/sync/mpsc/mod.rs)
- #77044 (Liballoc bench vec use mem take not replace)
- #77050 (Typo fix: "satsify" -> "satisfy")
- #77074 (add array::from_ref)
- #77078 (Don't use an if guard to check equality with a constant)
- #77079 (Use `Self` in docs when possible)
- #77081 (Merge two almost identical match arms)
- #77121 (Updated html_root_url for compiler crates)
- #77136 (Suggest `const_mut_refs`, not `const_fn` for mutable references in `const fn`)
- #77160 (Suggest `const_fn_transmute`, not `const_fn`)
- #77164 (Remove workaround for deref issue that no longer exists.)
- #77165 (Followup to #76673)
Jonas Schievink [Fri, 25 Sep 2020 00:29:49 +0000 (02:29 +0200)]
Rollup merge of #77160 - ecstatic-morse:const-fn-transmute-suggestion, r=oli-obk
Suggest `const_fn_transmute`, not `const_fn`
More fallout from #76850 in the vein of #77134. The fix is the same. I looked through the structured errors file and didn't see any more of this kind of diagnostics bug.
Jonas Schievink [Fri, 25 Sep 2020 00:29:47 +0000 (02:29 +0200)]
Rollup merge of #77136 - ecstatic-morse:issue-77134, r=oli-obk
Suggest `const_mut_refs`, not `const_fn` for mutable references in `const fn`
Resolves #77134.
Prior to #76850, most uses of `&mut` in `const fn` ~~required~~ involved two feature gates, `const_mut_refs` and `const_fn`. The first allowed all mutable borrows of locals. The second allowed only locals, arguments and return values whose types contained `&mut`. I switched the second check to the `const_mut_refs` gate. However, I forgot update the error message with the new suggestion.
Alternatively, we could revert to having two different feature gates for this. OP's code never borrows anything mutably, so it didn't need `const_mut_refs` in the past, only `const_fn`. I'd prefer to keep everything under a single gate, however.
Jonas Schievink [Fri, 25 Sep 2020 00:29:39 +0000 (02:29 +0200)]
Rollup merge of #77074 - lcnr:array-from-ref, r=SimonSapin
add array::from_ref
mirrors the methods in `std::slice` with the same name.
I guess this method previously didn't exist as there was close to no reason to create an array of size `1`.
This will change due to const generics in the near future.
Jonas Schievink [Fri, 25 Sep 2020 00:29:31 +0000 (02:29 +0200)]
Rollup merge of #76724 - ecstatic-morse:dataflow-pass-names, r=lcnr
Allow a unique name to be assigned to dataflow graphviz output
Previously, if the same analysis were invoked multiple times in a single compilation session, the graphviz output for later runs would overwrite that of previous runs. Allow callers to add a unique identifier to each run so this can be avoided.
Jonas Schievink [Fri, 25 Sep 2020 00:29:30 +0000 (02:29 +0200)]
Rollup merge of #76304 - CDirkx:const-ip, r=ecstatic-morse
Make delegation methods of `std::net::IpAddr` unstably const
Make the following methods of `std::net::IpAddr` unstable const under the `const_ip` feature:
- `is_unspecified`
- `is_loopback`
- `is_global`
- `is_multicast`
Also adds a test for these methods in a const context.
Possible because these methods delegate to the inner `Ipv4Addr` or `Ipv6Addr`, which were made const ([PR#76205](https://github.com/rust-lang/rust/pull/76142) and [PR#76206](https://github.com/rust-lang/rust/pull/76206)), and the recent stabilization of const control flow.
Jonas Schievink [Fri, 25 Sep 2020 00:29:22 +0000 (02:29 +0200)]
Rollup merge of #75438 - Cldfire:rustdoc/use-adaptive-svg-favicon, r=GuillaumeGomez
Use adaptive SVG favicon for rustdoc like other rust sites
Use the theme-adaptive SVG favicon that was recently introduced [for the Rust site](https://github.com/rust-lang/www.rust-lang.org/pull/1185) (and others).
(This PR is simply copied from the PR linked above, so see that for rationale.)
Auto merge of #76918 - ishitatsuyuki:match-fastpath, r=oli-obk
Add fast path for match checking
This adds a fast path that would reduce the complexity to linear on matches consisting of only variant patterns (i.e. enum matches). (Also see: #7462) Unfortunately, I was too lazy to add a similar fast path for constants (mostly for integer matches), ideally that could be added another day.
TBH, I'm not confident with the performance claims due to the fact that enums tends to be small and FxHashMap could add a lot of overhead.
We now walk the hir instead of using `ty` so that we get better spans here, While I am still not completely sure if that's
what we want in the end, it does seem a lot closer to the final goal than the previous version.
We also look into type aliases (and use a `TypeVisitor` here), about which I am not completely sure, but we will see how well this works.
We also look into fn decls, so the following should work now.
```rust
fn test<T>() -> [u8; std::mem::size_of::<T>()] {
[0; std::mem::size_of::<T>()]
}
```
Additionally, we visit the optional trait and self type of impls.
Auto merge of #76748 - tmiasko:no-op-jumps, r=matthewjasper
Fix underflow when calculating the number of no-op jumps folded
When removing unwinds to no-op blocks and folding jumps to no-op blocks,
remove the unwind target first. Otherwise we cannot determine if target
has been already folded or not.
Previous implementation incorrectly assumed that all resume targets had
been folded already, occasionally resulting in an underflow:
```
remove_noop_landing_pads: removed 18446744073709551613 jumps and 3 landing pads
```
Thanks to the great work of `@jyn514` in getting the [cross-crate reexport issue](https://github.com/rust-lang/rust/issues/65983) in intra-rustdoc links fixed, I think we're now in a position to stabilize this feature.
The tracking issue currently has two unresolved issues:
- <s>behavior around doc(hidden): This is fixed in https://github.com/rust-lang/rust/pull/73365, which is just waiting for CI and should land tomorrow. It's also a pretty niche bug so while I expect it to land soon I don't think we need to block stabilization on it anyway.</s>
- Non-identifier primitive types like slices: This was not a part of the original RFC anyway, and is a pretty niche use case
The feature itself, sans https://github.com/rust-lang/rust/issues/65983, has been shipped on nightly for three years now, with people using it on docs.rs. https://github.com/rust-lang/rust/issues/65983 itself is not an overwhelmingly central bit of functionality; the reason we elected to block stabilization on it was that back in 2017 it was not possible to fix the issue without some major refactorings of resolve, and we did not want to stabilize something that had such a potentially unfixable bug.
Given that we've fixed it, I see no reason to delay stabilization on this long awaited feature. It's possible that the latest patches have problems, however we _have_ done crater runs of some of the crucial parts. Furthermore, that's what the release trains are for, we will have a solid three months to let it ride the trains before it actually hits the stable compiler.
Auto merge of #77083 - KodrAus:revert/const-type-id, r=RalfJung
revert const_type_id stabilization
This reverts #72488, which is currently on beta and scheduled to stabilize in `1.47.0`, based on https://github.com/rust-lang/rust/pull/75923#issuecomment-696676511
It turns out we might not be quite ready to stabilize `TypeId` in const contexts before having a chance to rework its internals. Since `TypeId` is a bit of an oddity we want to be careful about how those internals are currently being relied on while making changes. That will be easier to do without having to also consider compile-time contexts.
projects / rust.git / log