Make `Bound::predicates` use `Clause`
Part of #107250
`Bound::predicates` returns an iterator over `Binder<_, Clause>` instead of `Predicate`.
I tried updating `explicit_predicates_of` as well, but it seems that it needs a lot more change than I thought. Will do it in a separate PR instead.
bootstrap: check for dry run when copying env vars for msvc
The new synthetic targets for mir-opt blessing aren't added to `builder.cc` during dry runs, causing `x.py test tests/mir-opt --bless` to crash on MSVC when it tries to copy env vars to the C compiler invocation. This PR adds a check for dry run to fix the panic.
std: only depend on dlmalloc for wasm*-unknown
It was already filtered out for emscripten, but wasi doesn't need dlmalloc
either since it reuses `unix/alloc.rs`.
io: soften ‘at most one write attempt’ requirement in io::Write::write
At the moment, documentation of std::io::Write::write indicates that
call to it ‘represents at most one attempt to write to any wrapped
object’. It seems that such wording was put there to contrast it with
pre-1.0 interface which attempted to write all the data (it has since
been changed in [RFC 517]).
However, the requirement puts unnecessary constraints and may
complicate adaptors which perform non-trivial transformations on the
data. For example, they may maintain an internal buffer which needs
to be written out before the write method accepts more data. It might
be natural to code the method such that it flushes the buffer and then
grabs another chunk of user data. With the current wording in the
documentation, the adaptor would be forced to return Ok(0).
This commit softens the wording such that implementations can choose
code structure which makes most sense for their particular use case.
While at it, elaborate on the meaning of `Ok(0)` return pointing out
that the write_all methods interprets it as an error.
[RFC 517]: https://rust-lang.github.io/rfcs/0517-io-os-reform.html
Launch a non-unwinding panic for misaligned pointer deref
This panic already never unwinds, but that's only because it always hits the unwind guard that's created by our `UnwindAction::Terminate`. Hitting the unwind guard generates a huge double-panic backtrace. Now we generate a normal-looking panic message when this check is hit.
r? `@thomcc`
Blessing 32-bit tests on 64-bit hosts relies on having a corresponding 32-bit
target that can be built "easily" on those hosts.
ARM Macs don't have a corresponding 32-bit target, so trying to build one is
usually going to fail.
fix: get the l4re target working again
This is based on work from https://github.com/rust-lang/rust/pull/103966, addressing the review comment by `@m-ou-se` at the time and "fixing" the (probably newly) missing read_buf.
Remove scope_for_def calls as the definition have been removed entirely.
As a result of this change the problem with false path resolutions has been solved.
Github action to periodically `cargo update` to keep dependencies current
Opens a PR periodically with the results of `cargo update`. If an unmerged PR for the branch `cargo_update` already exists, it will edit then reopen it if necessary.
~~This also uses [`cargo-upgrades`](https://gitlab.com/kornelski/cargo-upgrades) to provide a list of available major upgrades in the PR body.~~
It includes the list of changes output by `cargo update` in the commit message and PR body. Note that this output is currently sub-optimal due to https://github.com/rust-lang/cargo/issues/9408, but if updates are made more regularly that is less likely to show up.
Example PR: https://github.com/pitaj/rust/pull/2
Example action run: https://github.com/pitaj/rust/actions/runs/5035731903
Prior discussion: https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/dependabot.20updates.3F
Up for discussion:
- What period do we want? Currently weekly
- What user should it use? Currently "Github Actions"
- Do we need the extra security of provided by executing `cargo update` and `cargo-upgrades` in a separate job?
If not I can simplify it to not need artifacts.
- PR message wording
- PR should probably always be `rollup=always`?
- What branch should it use?
- What should it do if no updates are available? Currently fails the job on empty commit
- Should the yml file live in `src/ci` instead of directly under workflows?
- ~~Is using the latest nightly toolchain enough to ensure compatibility with `Cargo.lock` and `Cargo.toml`s in master?~~
Now pulls the bootstrap version from stage0.json
r? infra
Remove `box_free` lang item
This PR removes the `box_free` lang item, replacing it with `Box`'s `Drop` impl. Box dropping is still slightly magic because the contained value is still dropped by the compiler.
Adding configuration to allow safety comment above stmt containing unsafe block
Adding a new configuration, `accept-comment-above-statement`, to allow a safety comment to be placed before the statement that has the `unsafe` block. It affects the `undocumented_unsafe_blocks` lint.
The default value for this configuration will be `false`. So the user has to opt-in for the change.
This PR fixes https://github.com/rust-lang/rust-clippy/issues/10832
---
changelog: Enhancement [`undocumented_unsafe_blocks`]: Added `accept-comment-above-statement` configuration.
[#10886](https://github.com/rust-lang/rust-clippy/pull/10886)
Rollup of 6 pull requests
Successful merges:
- #112352 (Fix documentation build on FreeBSD)
- #112644 (Correct types in method descriptions of `NonZero*` types)
- #112683 (fix ICE on specific malformed asm clobber_abi)
- #112707 ([rustdoc] Fix invalid handling of "going back in history" when "go to only search result" setting is enabled)
- #112719 (Replace fvdl with ffx, allow test without install)
- #112728 (Add `<meta charset="utf-8">` to `-Zdump-mir-spanview` output)
r? `@ghost`
`@rustbot` modify labels: rollup
