Dylan MacKenzie [Sat, 3 Oct 2020 21:38:01 +0000 (14:38 -0700)]
Allow `Abort` terminators in a const-context
These appear along the cleanup path inside functions with
`#[unwind(aborts)]`. We don't const-check the cleanup path anyways,
since const-eval already has "abort-on-panic" semantics and there's
often drops that would otherwise be forbidden, so the check wasn't
really preventing anything anyways.
bors [Fri, 2 Oct 2020 19:42:07 +0000 (19:42 +0000)]
Auto merge of #77462 - jonas-schievink:rollup-m0rqdh5, r=jonas-schievink
Rollup of 12 pull requests
Successful merges:
- #76101 (Update RELEASES.md for 1.47.0)
- #76739 (resolve: prohibit anon const non-static lifetimes)
- #76811 (Doc alias name restriction)
- #77405 (Add tracking issue of iter_advance_by feature)
- #77409 (Add example for iter chain struct)
- #77415 (Better error message for `async` blocks in a const-context)
- #77423 (Add `-Zprecise-enum-drop-elaboration`)
- #77432 (Use posix_spawn on musl targets)
- #77441 (Fix AVR stack corruption bug)
- #77442 (Clean up on example doc fixes for ptr::copy)
- #77444 (Fix span for incorrect pattern field and add label)
- #77453 (Stop running macOS builds on Azure Pipelines)
Jonas Schievink [Fri, 2 Oct 2020 18:27:18 +0000 (20:27 +0200)]
Rollup merge of #77453 - pietroalbini:ci-no-more-azure, r=Mark-Simulacrum
Stop running macOS builds on Azure Pipelines
The Infrastructure Team agreed to migrate macOS builds to GitHub Actions, so this commit stops running those builders on Azure Pipelines. The GitHub Actions runners are already configured to upload to the production bucket.
We can't still fully remove the Azure Pipelines configuration, as we still need to have that available until no stable releases run any of their builds on Azure Pipelines anymore. I'll open an issue to track fully removing our Azure Pipelines setup once the PR is merged.
Jonas Schievink [Fri, 2 Oct 2020 18:27:11 +0000 (20:27 +0200)]
Rollup merge of #77432 - tmiasko:posix-spawn-musl, r=cuviper
Use posix_spawn on musl targets
The posix_spawn had been available in a form suitable for use in a
Command implementation since musl 0.9.12. Use it in a preference to a
fork when possible, to benefit from CLONE_VM|CLONE_VFORK used there.
Jonas Schievink [Fri, 2 Oct 2020 18:27:09 +0000 (20:27 +0200)]
Rollup merge of #77423 - ecstatic-morse:discriminant-switch-effect-config, r=pnkfelix
Add `-Zprecise-enum-drop-elaboration`
Its purpose is to assist in debugging #77382 and #74551. Passing `-Zprecise-enum-drop-elaboration=no` will turn off the added precision that seems to be causing issues on some platforms. This assumes that we can reproduce #77382 on the latest master. I should have done this earlier. Oh well.
Jonas Schievink [Fri, 2 Oct 2020 18:26:55 +0000 (20:26 +0200)]
Rollup merge of #76739 - davidtwco:issue-75323-non-static-lifetime-in-anonconst, r=varkor
resolve: prohibit anon const non-static lifetimes
Fixes #75323, fixes #74447 and fixes #73375.
This PR prohibits non-static lifetimes in anonymous constants when only the `min_const_generics` feature is enabled. ~~To do so, `to_region_vid`'s `bug!` had to be changed into a delayed bug, which unfortunately required providing it a `TyCtxt`.~~
---
~~While I am happy with how the implementation of the error turned out in `rustc_passes::check_const`, emitting an error wasn't sufficient to avoid hitting the ICE later. I also tried implementing the error in `rustc_mir::transform::check_consts::validation` and that worked, but it didn't silence the ICE either. To silence the ICE, I changed it to a delayed bug which worked but was more invasive that I would have liked, and required I return an incorrect lifetime. It's possible that this check should be implemented earlier in the compiler to make the invasive changes unnecessary, but I wasn't sure where that would be and wanted to get some feedback first.~~
The approach taken by this PR has been changed to implement the error in name resolution, which ended up being much simpler.
bors [Fri, 2 Oct 2020 13:22:26 +0000 (13:22 +0000)]
Auto merge of #77418 - pietroalbini:ci-environment-files, r=Mark-Simulacrum
Switch to environment files to change the environment on GHA
This PR switches our CI to use GitHub's new [environment files](https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-commands-for-github-actions#environment-files) to set environment variables and add items to `$PATH`, as GitHub [plans to disable the old `::set-env` and `::add-path` log commands](https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/) due to a [security issue](https://github.com/actions/toolkit/security/advisories/GHSA-mfwh-5m23-j46w).
Our self-hosted runners are on version 2.273.4, so they already have support for this.
David Wood [Tue, 15 Sep 2020 13:38:41 +0000 (14:38 +0100)]
resolve: prohibit anon const non-static lifetimes
This commit modifies name resolution to emit an error when non-static
lifetimes are used in anonymous constants when the `min_const_generics`
feature is enabled.
bors [Fri, 2 Oct 2020 07:51:24 +0000 (07:51 +0000)]
Auto merge of #77029 - ehuss:command-access, r=dtolnay
Add accessors to Command.
This adds some accessor methods to `Command` to provide a way to access the values set when building the `Command`. An example where this can be useful is to display the command to be executed. This is roughly based on the [`ProcessBuilder`](https://github.com/rust-lang/cargo/blob/13b73cdaf76b2d9182515c9cf26a8f68342d08ef/src/cargo/util/process_builder.rs#L105-L134) in Cargo.
Possible concerns about the API:
- Values with NULs on Unix will be returned as `"<string-with-nul>"`. I don't think it is practical to avoid this, since otherwise a whole separate copy of all the values would need to be kept in `Command`.
- Does not handle `arg0` on Unix. This can be awkward to support in `get_args` and is rarely used. I figure if someone really wants it, it can be added to `CommandExt` as a separate method.
- Does not offer a way to detect `env_clear`. I'm uncertain if it would be useful for anyone.
- Does not offer a way to get an environment variable by name (`get_env`). I figure this can be added later if anyone really wants it. I think the motivation for this is weak, though. Also, the API could be a little awkward (return a `Option<Option<&OsStr>>`?).
- `get_envs` could skip "cleared" entries and just return `&OsStr` values instead of `Option<&OsStr>`. I'm on the fence here. My use case is to display a shell command, and I only intend it to be roughly equivalent to the actual execution, and I probably won't display `None` entries. I erred on the side of providing extra information, but I suspect many situations will just filter out the `None`s.
- Could implement more iterator stuff (like `DoubleEndedIterator`).
I have not implemented new std items before, so I'm uncertain if the existing issue should be reused, or if a new tracking issue is needed.
bors [Fri, 2 Oct 2020 00:48:41 +0000 (00:48 +0000)]
Auto merge of #77436 - JohnTitor:rollup-65dh7rp, r=JohnTitor
Rollup of 11 pull requests
Successful merges:
- #76851 (Fix 'FIXME' about using NonZeroU32 instead of u32.)
- #76979 (Improve std::sys::windows::compat)
- #77111 (Stabilize slice_ptr_range.)
- #77147 (Split sys_common::Mutex in StaticMutex and MovableMutex.)
- #77312 (Remove outdated line from `publish_toolstate` hook)
- #77362 (Fix is_absolute on WASI)
- #77375 (rustc_metadata: Do not forget to encode inherent impls for foreign types)
- #77385 (Improve the example for ptr::copy)
- #77389 (Fix some clippy lints)
- #77399 (BTreeMap: use Unique::from to avoid a cast where type information exists)
- #77429 (Link `new` method in `DefautHasher`s doc)
Yuki Okushi [Thu, 1 Oct 2020 23:25:19 +0000 (08:25 +0900)]
Rollup merge of #77362 - RReverser:patch-1, r=dtolnay
Fix is_absolute on WASI
WASI does not match `cfg(unix)`, but its paths are Unix-like (`/some/path`) and don't have Windows-like prefixes.
Without this change, `is_absolute` for any paths, including `/some/path`, was returning `false`on a WASI target, which is obviously not true and undesirable.
Yuki Okushi [Thu, 1 Oct 2020 23:25:15 +0000 (08:25 +0900)]
Rollup merge of #77147 - fusion-engineering-forks:static-mutex, r=dtolnay
Split sys_common::Mutex in StaticMutex and MovableMutex.
The (unsafe) `Mutex` from `sys_common` had a rather complicated interface. You were supposed to call `init()` manually, unless you could guarantee it was neither moved nor used reentrantly.
Calling `destroy()` was also optional, although it was unclear if 1) resources might be leaked or not, and 2) if `destroy()` should only be called when `init()` was called.
This allowed for a number of interesting (confusing?) different ways to use this `Mutex`, all captured in a single type.
In practice, this type was only ever used in two ways:
1. As a static variable. In this case, neither `init()` nor `destroy()` are called. The variable is never moved, and it is never used reentrantly. It is only ever locked using the `LockGuard`, never with `raw_lock`.
2. As a `Box`ed variable. In this case, both `init()` and `destroy()` are called, it will be moved and possibly used reentrantly.
No other combinations are used anywhere in `std`.
This change simplifies things by splitting this `Mutex` type into two types matching the two use cases: `StaticMutex` and `MovableMutex`.
The interface of both new types is now both safer and simpler. The first one does not call nor expose `init`/`destroy`, and the second one calls those automatically in its `new()` and `Drop` functions. Also, the locking functions of `MovableMutex` are no longer unsafe.
---
This will also make it easier to conditionally box mutexes later, by moving that decision into sys/sys_common. Some of the mutex implementations (at least those of Wasm and 'sys/unsupported') are safe to move, so wouldn't need a box. ~~(But that's blocked on #76932 for now.)~~ (See #77380.)
Yuki Okushi [Thu, 1 Oct 2020 23:25:11 +0000 (08:25 +0900)]
Rollup merge of #76979 - fusion-engineering-forks:windows-fallback-check, r=dtolnay
Improve std::sys::windows::compat
Improves the compat_fn macro in sys::windows, which is used for conditionally loading APIs that might not be available.
- The module (dll) name can now be any string, not just an ident. (Not all Windows api modules are valid Rust identifiers. E.g. `WaitOnAddress` comes from `API-MS-Win-Core-Synch-l1-2-0.dll`.)
- Adds `FuncName::is_available()` for checking if a function is really available without having to do a duplicate lookup.
- Add comment explaining the lack of locking.
- Use `$_:block` to simplify the macro_rules.
- Apply `allow(unused_variables)` only to the fallback instead of everything.
---
The second point (`is_available()`) simplifies code that needs to pick an implementation depening on what is available, like `sys/windows/mutex.rs`. Before this change, it'd do its own lookup and keep its own `AtomicUsize` to track the result. Now it can just use `c::AcquireSRWLockExclusive::is_available()` directly.
This will also be useful when park/unpark/CondVar/etc. get improved implementations (e.g. from parking_lot or something else), as the best APIs for those are not available before Windows 8.
bors [Thu, 1 Oct 2020 18:16:02 +0000 (18:16 +0000)]
Auto merge of #76971 - bugadani:issue-75659, r=Amanieu
Refactor memchr to allow optimization
Closes #75659
The implementation already uses naive search if the slice if short enough, but the case is complicated enough to not be optimized away. This PR refactors memchr so that it exists early when the slice is short enough.
Codegen-wise, as shown in #75659, memchr was not inlined previously so the only way I could find to test this is to check if there is no memchr call. Let me know if there is a more robust solution here.
Mara Bos [Sun, 20 Sep 2020 12:46:10 +0000 (14:46 +0200)]
Improve std::sys::windows::compat.
- Module name can now be any string, not just an ident.
(Not all Windows api modules are valid Rust identifiers.)
- Adds c::FuncName::is_available() for checking if a function is really
available without having to do a duplicate lookup.
- Add comment explaining the lack of locking.
- Use `$_:block` to simplify the macro_rules.
- Apply allow(unused_variables) only to the fallback instead of
everything.
bors [Thu, 1 Oct 2020 13:21:34 +0000 (13:21 +0000)]
Auto merge of #76919 - fusion-engineering-forks:thread-parker, r=dtolnay
Use futex-based thread::park/unpark on Linux.
This moves the parking/unparking logic out of `thread/mod.rs` into a module named `thread_parker` in `sys_common`. The current implementation is moved to `sys_common/thread_parker/generic.rs` and the new implementation using futexes is added in `sys_common/thread_parker/futex.rs`.
bors [Thu, 1 Oct 2020 07:38:47 +0000 (07:38 +0000)]
Auto merge of #77354 - ecstatic-morse:const-checking-moar-errors, r=oli-obk
Overhaul const-checking diagnostics
The primary purpose of this PR was to remove `NonConstOp::STOPS_CONST_CHECKING`, which causes any additional errors found by the const-checker to be silenced. I used this flag to preserve diagnostic parity with `qualify_min_const_fn.rs`, which has since been removed.
However, simply removing the flag caused a deluge of errors in some cases, since an error would be emitted any time a local or temporary had a wrong type. To remedy this, I added an alternative system (`DiagnosticImportance`) to silence additional error messages that were likely to distract the user from the underlying issue. When an error of the highest importance occurs, all less important errors are silenced. When no error of the highest importance occurs, all less important errors are emitted after checking is complete. Following the suggestions from the important error is usually enough to fix the less important errors, so this should lead to better UX most of the time.
There's also some unrelated diagnostics improvements in this PR isolated in their own commits. Splitting them out would be possible, but a bit of a pain. This isn't as tidy as some of my other PRs, but it should *only* affect diagnostics, never whether or not something passes const-checking. Note that there are a few trivial exceptions to this, like banning `Yield` in all const-contexts, not just `const fn`.
Dylan DPC [Thu, 1 Oct 2020 00:13:41 +0000 (02:13 +0200)]
Rollup merge of #77319 - tgnottingham:siphasher_endianness, r=nnethercote
Stable hashing: add comments and tests concerning platform-independence
SipHasher128 implements short_write in an endian-independent way, yet
its write_xxx Hasher trait methods undo this endian-independence by byte
swapping the integer inputs on big-endian hardware. StableHasher then
adds endian-independence back by also byte-swapping on big-endian
hardware prior to invoking SipHasher128.
This double swap may have the appearance of being a no-op, but is in
fact by design. In particular, we really do want SipHasher128 to be
platform-dependent, in order to be consistent with the libstd SipHasher.
Try to clarify this intent. Also, add and update a couple of unit tests.
~StableHasher is supposed to ensure platform independence by converting
integers to little-endian and extending isize and usize to 64 bits as
necessary, but in fact, much of that work is already handled by
SipHasher128.~
~In particular, SipHasher128 implements short_write in an
endian-independent way, yet both StableHasher and SipHasher128
additionally attempt to achieve endian-independence by byte swapping on
BE hardware before invoking short writes. This double swap has no
effect, so let's remove it.~
~Because short_write is endian-independent, SipHasher128 is already
handling part of the platform-independence, and it would be somewhat
difficult to make it *not* handle that part with the current
implementation. As splitting platform-independence responsibilities
between StableHasher and SipHasher128 would be confusing, let's make
SipHasher128 handle all of it.~
~Finally, update some incorrect comments and increase test coverage.
Unit tests pass on both LE and BE systems.~
Dylan DPC [Thu, 1 Oct 2020 00:13:35 +0000 (02:13 +0200)]
Rollup merge of #77303 - lcnr:const-evaluatable-TooGeneric, r=oli-obk,varkor
const evaluatable: improve `TooGeneric` handling
Instead of emitting an error in `fulfill`, we now correctly stall on inference variables.
As `const_eval_resolve` returns `ErrorHandled::TooGeneric` when encountering generic parameters on which
we actually do want to error, we check for inference variables and eagerly emit an error if they don't exist, returning `ErrorHandled::Reported` instead.
Also contains a small bugfix for `ConstEquate` where we previously only stalled on type variables. This is probably a leftover from
when we did not yet support stalling on const inference variables.
Dylan DPC [Thu, 1 Oct 2020 00:13:34 +0000 (02:13 +0200)]
Rollup merge of #77202 - ehuss:defer-apple-sdkroot, r=petrochenkov
Defer Apple SDKROOT detection to link time.
This defers the detection of the SDKROOT for Apple iOS/tvOS targets to link time, instead of when the `Target` is defined. This allows commands that don't need to link to work (like `rustdoc` or `rustc --print=target-list`). This also makes `--print=target-list` a bit faster.
This also removes the note in the platform support documentation about these targets being missing. When I wrote it, I misunderstood how the SDKROOT stuff worked.
Notes:
* This means that JSON spec targets can't explicitly override these flags. I think that is probably fine, as I believe the value is generally required, and can be set with the SDKROOT environment variable.
* This changes `x86_64-apple-tvos` to use `appletvsimulator`. I think the original code was wrong (it was using `iphonesimulator`). Also, `x86_64-apple-tvos` seems broken in general, and I cannot build it locally. The `data_layout` does not appear to be correct (it is a copy of the arm64 layout instead of the x86_64 layout). I have not tried building Apple's LLVM to see if that helps, but I suspect it is just wrong (I'm uncertain since I don't know how the tvOS simulator works with its bitcode-only requirements).
* I'm tempted to remove the use of `Result` for built-in target definitions, since I don't think they should be fallible. This was added in https://github.com/rust-lang/rust/pull/34980, but that only relates to JSON definitions. I think the built-in targets shouldn't fail. I can do this now, or not.
Dylan DPC [Thu, 1 Oct 2020 00:13:32 +0000 (02:13 +0200)]
Rollup merge of #77153 - Aaron1011:fix/better-recursive-expand, r=petrochenkov
Fix recursive nonterminal expansion during pretty-print/reparse check
Makes progress towards #43081
In PR #73084, we started recursively expanded nonterminals during the
pretty-print/reparse check, allowing them to be properly compared
against the reparsed tokenstream.
Unfortunately, the recursive logic in that PR only handles the case
where a nonterminal appears inside a `TokenTree::Delimited`. If a
nonterminal appears directly in the expanded tokens of another
nonterminal, the inner nonterminal will not be expanded.
This PR fixes the recursive expansion of nonterminals, ensuring that
they are expanded wherever they occur.
that advances the iterator by `n` elements, returning `Ok(())` if this succeeds or `Err(len)` if the length of the iterator was less than `n`.
Currently `Iterator::nth` is the method to override for efficiently advancing an iterator by multiple elements at once. `advance_by` is superior for this purpose because
- it's simpler to implement: instead of advancing the iterator and producing the next element you only need to advance the iterator
- it composes better: iterators like `Chain` and `FlatMap` can implement `advance_by` in terms of `advance_by` on their inner iterators, but they cannot implement `nth` in terms of `nth` on their inner iterators (see #60395)
- the default implementation of `nth` can trivially be implemented in terms of `advance_by` and `next`, which this PR also does
This PR also adds `DoubleEndedIterator::advance_back_by` for all the same reasons.
I'll make a tracking issue if it's decided this is worth merging. Also let me know if anything can be improved, this went through several iterations so there might very well still be room for improvement (especially in the doc comments). I've written overrides of these methods for most iterators that already override `nth`/`nth_back`, but those still need tests so I'll add them in a later PR.
Tomasz Miąsko [Thu, 1 Oct 2020 00:00:00 +0000 (00:00 +0000)]
Use posix_spawn on musl targets
The posix_spawn had been available in a form suitable for use in a
Command implementation since musl 0.9.12. Use it in a preference to a
fork when possible, to benefit from CLONE_VM|CLONE_VFORK used there.
Auto merge of #76325 - lzutao:split-core-str, r=Amanieu
Split core/str/mod.rs to smaller files
Note for reviewer:
* I split to multiple commits for easier reviewing, but I could git squash them all to one if requested.
* Recommend pulling this change locally and using advanced git diff viewer or this command:
```bash
git show --reverse --color-moved=dimmed-zebra --color-moved-ws=ignore-all-space master..
```
---
I split `core/str/mod.rs` to these modules:
* `converts`: Contains helper functions to convert from bytes to str.
* `error`: For error structs like Utf8Error.
* `iter`: For iterators of many str methods.
* `traits`: For indexing operations and build in traits on str.
* `validations`: For functions validating utf8 --- This name is awkward, maybe utf8.rs is better.
Auto merge of #77372 - jonas-schievink:rollup-e5bdzga, r=jonas-schievink
Rollup of 12 pull requests
Successful merges:
- #77037 (more tiny clippy cleanups)
- #77233 (BTreeMap: keep an eye out on the size of the main components)
- #77280 (Ensure that all LLVM components requested by tests are available on CI)
- #77284 (library: Forward compiler-builtins "mem" feature)
- #77296 (liveness: Use Option::None to represent absent live nodes)
- #77322 (Add unstable book docs for `-Zunsound-mir-opts`)
- #77328 (Use `rtassert!` instead of `assert!` from the child process after fork() in std::sys::unix::process::Command::spawn())
- #77331 (Add test for async/await combined with const-generics.)
- #77338 (Fix typo in alloc vec comment)
- #77340 (Alloc vec use imported path)
- #77345 (Add test for issue #74761)
- #77348 (Update books)
Jonas Schievink [Wed, 30 Sep 2020 18:56:24 +0000 (20:56 +0200)]
Rollup merge of #77348 - ehuss:update-books, r=ehuss
Update books
## rust-by-example
5 commits in 19f0a0372af497b34369cf182d9d16156cab2969..7d3ff1c12db08a847a57a054be4a7951ce532d2d
2020-08-26 09:38:48 -0300 to 2020-09-28 15:54:25 -0300
- Prevent duplicated error information in "wrapping errors" example (rust-lang/rust-by-example#1375)
- Avoid lifetime annotation in struct example (rust-lang/rust-by-example#1378)
- Clone.md comment and variable name change (rust-lang/rust-by-example#1379)
- Replace panic example with a simpler version (rust-lang/rust-by-example#1380)
- Prefer `const` over `static` (rust-lang/rust-by-example#1381)
projects / rust.git / log