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.
Auto merge of #77102 - Dylan-DPC:rollup-2jfrg3u, r=Dylan-DPC
Rollup of 9 pull requests
Successful merges:
- #76898 (Record `tcx.def_span` instead of `item.span` in crate metadata)
- #76939 (emit errors during AbstractConst building)
- #76965 (Add cfg(target_has_atomic_equal_alignment) and use it for Atomic::from_mut.)
- #76993 (Changing the alloc() to accept &self instead of &mut self)
- #76994 (fix small typo in docs and comments)
- #77017 (Add missing examples on Vec iter types)
- #77042 (Improve documentation for ToSocketAddrs)
- #77047 (Miri: more informative deallocation error messages)
- #77055 (Add #[track_caller] to more panicking Cell functions)
Make delegation methods of `std::net::IpAddr` unstable 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, and the recent stabilization of const control flow.
Rollup merge of #77055 - est31:more_track_caller, r=Mark-Simulacrum
Add #[track_caller] to more panicking Cell functions
Continuation of #74526
Adds the #[track_caller] attribute to almost all panicking Cell
functions. The ones that borrow two Cells in their function
body are spared, because the panic location helps pinpoint
which of the two borrows failed. You'd need to have
full debuginfo and backtraces enabled together with column
info in order to be able to discern the cases.
Column info in debuginfo is only available on non-Windows platforms.
Auto merge of #76850 - ecstatic-morse:const-checking-refactor, r=oli-obk
Remove `qualify_min_const_fn`
~~Blocked on #76807 (the first six commits).~~
With this PR, all checks in `qualify_min_const_fn` are replicated in `check_consts`, and the former is no longer invoked. My goal was to have as few changes to test output as possible, since making sweeping changes to the code *while* doing big batches of diagnostics updates turned out to be a headache. To this end, there's a few `HACK`s in `check_consts` to achieve parity with `qualify_min_const_fn`.
The new system that replaces `is_min_const_fn` is referred to as "const-stability" My end goal for the const-stability rules is this:
* Const-stability is only applicable to functions defined in `staged_api` crates.
* All functions not marked `rustc_const_unstable` are considered "const-stable".
- NB. This is currently not implemented. `#[unstable]` functions are also const-unstable. This causes problems when searching for feature gates.
- All "const-unstable" functions have an associated feature gate
* const-stable functions can only call other const-stable functions
- `allow_internal_unstable` can be used to circumvent this.
* All const-stable functions are subject to some additional checks (the ones that were unique to `qualify_min_const_fn`)
The plan is to remove each `HACK` individually in subsequent PRs. That way, changes to error message output can be reviewed in isolation.
Auto merge of #76810 - Mark-Simulacrum:fix-lld-macos, r=alexcrichton
Don't dynamically link LLVM tools unless rustc is too
This PR initially tried to support link-shared on all of our target platforms (other than Windows), but ran into a number of difficulties:
* LLVM doesn't really support a shared link on macOS (llvm-config runs into problems with the version suffix)
* LLVM doesn't seem to support a shared link when cross-compiling (the libLLVM.so ends up empty and symbols are not found)
So, this PR has now been revised such that we don't attempt to dynamically link LLVM tools (even if that would, otherwise, be supported) on targets where LLVM is statically linked to rustc. Currently that's basically everything except for x86_64-unknown-linux-gnu (where we dynamically link to avoid rerunning ThinLTO in each stage).
Add #[track_caller] to more panicking Cell functions
Continuation of #74526
Adds the #[track_caller] attribute to almost all panicking Cell
functions. The ones that borrow two Cells in their function
body are spared, because the panic location helps pinpoint
which of the two borrows failed. You'd need to have
full debuginfo and backtraces enabled together with column
info in order to be able to discern the cases.
Column info is only available on non-Windows platforms.
Auto merge of #76110 - FedericoPonzi:convert-openoptions-cint, r=JoshTriplett
Function to convert OpenOptions to c_int
Fixes: #74943
The creation_mode and access_mode function were already available in the OpenOptions struct, but currently private. I've added a new free functions to unix/fs.rs which takes the OpenOptions, and returns the c_int to be used as parameter for the `open` call.
Auto merge of #76626 - jyn514:x.py-changelog, r=Mark-Simulacrum
Add a changelog for x.py and nag contributors until they read it
Add a changelog for x.py
- Add a changelog and instructions for updating it
- Use `changelog-seen` in `config.toml` and `VERSION` in bootstrap to determine whether the changelog has been read. There's no way to tie reading the changelog to updating the version, so unfortunately they still have to update `config.toml` manually. Actually reading the changelog is optional, anyone can set `changelog-seen = N` without reading (although it's not recommended).
- Nag people if they haven't read the x.py changelog
+ Print message twice to make sure it's seen
- Give different error messages depending on whether the version needs to be updated or added