| Age | Commit message (Collapse) | Author | Lines |
|---|
|
make mir dataflow graphviz dumps opt-in
This should save some MIR traversals and allocations that are not really needed.
Small win but noticeable locally. Let's see what LTO/PGO say.
r? `@ghost`
|
|
Rollup of 6 pull requests
Successful merges:
- #112537 (Don't record adjustments twice in `note_source_of_type_mismatch_constraint`)
- #112663 (cleanup azure leftovers)
- #112668 (Test `x.ps1` in `msvc` CI job)
- #112710 (Re-use the deref-pattern recursion instead of duplicating the logic)
- #112753 (Don't try to auto-bless 32-bit `mir-opt` tests on ARM Mac hosts)
- #112758 (refactor(resolve): delete update_resolution function)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
refactor(resolve): delete update_resolution function
The `{ resolution.single_imports.remove(); }` code block does not modify the `binding` of this `resolution`. Therefore, the result of `resolution.binding()` before and after `let t = f(self, resolution)` will remain the same, and it will always satisfy the result: `_ if old_binding.is_some() => return t` or `None => return t`.
And then we delete the `update_resolution` function because it only called once.
r? ``@petrochenkov``
|
|
Don't try to auto-bless 32-bit `mir-opt` tests on ARM Mac hosts
#112418 added special support for automatically blessing 32-bit output on 64-bit hosts, for the subset of `mir-opt` tests that are pointer-width-dependent.
This relies on the 64-bit host having some corresponding 32-bit target that can be built “easily”. For most 64-bit hosts this is fine, but ARM Macs don't have a corresponding 32-bit target. (There have never been 32-bit ARM Macs, and ARM Macs don't have the libraries needed for building `i686-apple-darwin`.)
There is an entry for `("i686-apple-darwin", "aarch64-apple-darwin")` in the list of corresponding 32-bit platforms, but this doesn't actually work on ARM Macs. Instead, the bootstrap invocation fails to build the necessary 32-bit target support, and nothing gets tested or blessed.
According to [this Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Can't.20bless.20any.20mir-opt.20tests.20on.20aarch64.20Mac/near/367109789), that mapping was only added because the author assumed it would work. But since it doesn't actually work on ARM Macs, the solution is to just remove that mapping.
With the mapping removed, ARM Macs still can't auto-bless 32-bit output (they will see a warning instead), but at least they can now bless the output of `mir-opt` tests that don't care about pointer width.
|
|
Re-use the deref-pattern recursion instead of duplicating the logic
This essentially just removes code duplication
|
|
Test `x.ps1` in `msvc` CI job
Small adjustment to https://github.com/rust-lang/rust/pull/112633, to resolve [this comment](https://github.com/rust-lang/rust/pull/112633#issuecomment-1592973577).
r? `@pietroalbini`
|
|
cleanup azure leftovers
Continuation of #97756
|
|
r=cjgillot
Don't record adjustments twice in `note_source_of_type_mismatch_constraint`
We call `lookup_method` a few times in `note_source_of_type_mismatch_constraint`, but that function has side-effects to the typeck results. Replace it with a less side-effect-y variant of the function for use in diagnostics.
Specifically the ICE in #112532 happens because we're recording deref adjustments twice for a call receiver, which causes `ExprUseVisitor` to be angry.
Fixes #112532
|
|
CI: merge `mingw` test CI jobs
Same as https://github.com/rust-lang/rust/pull/112633, but for `mingw`. From the logs it looks like the runner spends 40 minutes compiling `rustc`, and then `10`/`20` minutes running tests. It seems wasteful to split that into two jobs.
CI run: https://github.com/rust-lang/rust/actions/runs/5275702134/jobs/9541479343?pr=112645
r? `@jyn514`
|
|
Don't capture `&[T; N]` when contents isn't read
Fixes the check in #111831
Fixes #112607, although I decided to test the root cause rather than including the example in the issue as a test.
cc `@BoxyUwU`
|
|
|
|
Switch the BB CFG cache from postorder to RPO
The `BasicBlocks` CFG cache is interesting:
- it stores a postorder, but `traversal::postorder` doesn't use it
- `traversal::reverse_postorder` does traverse the postorder cache backwards
- we do more RPO traversals than postorder traversals (around 20x on the perf.rlo benchmarks IIRC) but it's not cached
- a couple places here and there were manually reversing the non-cached postorder traversal
This PR switches the order of the cache, and makes a bit more use of it. This is a tiny win locally, but it's also for consistency and aesthetics.
r? `@ghost`
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #107200 (io: soften ‘at most one write attempt’ requirement in io::Write::write)
- #112667 (Move WF/ConstEvaluatable goal to clause)
- #112685 (std: only depend on dlmalloc for wasm*-unknown)
- #112722 (bootstrap: check for dry run when copying env vars for msvc)
- #112734 (Make `Bound::predicates` use `Clause`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
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`.
|
|
Move WF/ConstEvaluatable goal to clause
It can show up in a param-env, so I think it needs to be a clause kind.
r? ```@lcnr``` or ```@oli-obk```
|
|
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.
|
|
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #110805 (Github action to periodically `cargo update` to keep dependencies current)
- #112435 (Allow overwriting the sysroot compile flag via --rustc-args)
- #112610 (Bump stdarch)
- #112619 (Suggest bumping download-ci-llvm-stamp if the build config for llvm changes)
- #112738 (make ice msg "Unknown runtime phase" a bit nicer)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
make ice msg "Unknown runtime phase" a bit nicer
|
|
Suggest bumping download-ci-llvm-stamp if the build config for llvm changes
This will hopefully avoid issues like https://github.com/rust-lang/rust/issues/110474 where the uploaded `rust-dev` component doesn't match the one you'd get if you built LLVM from source.
cc https://github.com/rust-lang/rust/issues/110474#issuecomment-1516403887
|
|
Bump stdarch
In particular to pick up the stabilization of the AVX512 types (but not intrinsics) that was FCPed in https://github.com/rust-lang/stdarch/pull/1436.
|
|
Allow overwriting the sysroot compile flag via --rustc-args
Hi.
As discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/How.20to.20overwrite.20sysroot.20in.20x.2Epy.20test/near/364272269), this is a solution to allow the codegens to overwrite the sysroot as part of their test suite.
Thanks for the review.
|
|
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.
|
|
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
|
|
|
|
Add `<meta charset="utf-8">` to `-Zdump-mir-spanview` output
Without an explicit `<meta charset>` declaration, some browsers (e.g. Safari) won't detect the page encoding as UTF-8, causing unicode characters in the dump output to display incorrectly.
|
|
Replace fvdl with ffx, allow test without install
Along with replacing fvdl uses with the equivalent ffx commands, this also switches from using the install path for libstd-*.so and libtest-*.so to using the build directory (now passed on the command line). The user no longer needs to run x.py install before running tests now, and the correct libstd and libtest are detected on run instead of startup so the test runner can handle recompilations after starting the testing environment.
r? ``@tmandry``
|
|
[rustdoc] Fix invalid handling of "going back in history" when "go to only search result" setting is enabled
You can test the fix [here](https://rustdoc.crud.net/imperio/back-in-history-fix/lib2/index.html). Enable "Directly go to item in search if there is only one result", then search for `HasALongTraitWithParams` and finally go back to previous page. It should be back on the `index.html` page.
The reason for this bug is that the JS state is cached as is, so when we go back to the page, it resumes where it was left, somewhat (very weird), meaning the search is run again etc. The best way to handle this is to force the JS re-execution in this case so that it doesn't try to resume from where it left and then lead us back to the current page.
r? ``@notriddle``
|
|
fix ICE on specific malformed asm clobber_abi
fixes #112635
|
|
Correct types in method descriptions of `NonZero*` types
- `$Int`: e.g. i32, usize
- `$Ty`: e.g. NonZeroI32, NonZeroUsize
|method|current description|after my changes|
|-|-|-|
|`saturating_add`|...Return `$Int`::MAX on overflow.|...Return `$Ty`::MAX on overflow.|
|`checked_abs`|...returns None if self == `$Int`::MIN.|...returns None if self == `$Ty`::MIN.|
|`checked_neg`|...returning None if self == i32::MIN.|...returning None if self == `$Ty`::MIN.|
|`saturating_neg`|...returning MAX if self == i32::MIN...|...returning `$Ty`::MAX if self == `$Ty`::MIN...|
|`saturating_mul`|...Return `$Int`::MAX...|...Return `$Ty`::MAX...|
|`saturating_pow`|...Return `$Int`::MIN or `$Int`::MAX...|...Return `$Ty`::MIN or `$Ty`::MAX...|
---
For example:
```rust
pub const fn saturating_neg(self) -> NonZeroI128
```
- current
- Saturating negation. Computes `-self`, returning `MAX` if `self == i32::MIN` instead of overflowing.
- after my changes
- Saturating negation. Computes `-self`, returning `NonZeroI128::MAX` if `self == NonZeroI128::MIN` instead of overflowing.
|
|
Fix documentation build on FreeBSD
After the socket ancillary data implementation was introduced, the documentation build was broken on FreeBSD hosts, add the same workaround as for the existing implementations.
Fixes the doc build after #91793
|
|
Extend io::copy buffer reuse to BufReader too
previously it was only able to use BufWriter. This was due to a limitation in the BufReader generics that prevented specialization. This change works around the issue by using `BufReader where Self: Read` instead of `BufReader<I> where I: Read`. This limits our options, e.g. we can't access the inner reader, but it happens to work out if we rely on some implementation details.
Copying 1MiB from `/dev/zero` to `/dev/null` through a 256KiB BufReader yields following improvements
```
OLD:
io::copy::tests::bench_copy_buf_reader 51.44µs/iter +/- 703.00ns
NEW:
io::copy::tests::bench_copy_buf_reader 18.55µs/iter +/- 237.00ns
```
Previously this would read 256KiB into the reader but then copy 8KiB chunks to the writer through an additional intermediate buffer inside `io::copy`. Since those devices don't do much work most of the speedup should come from fewer syscalls and avoided memcopies.
The b3sum crate [notes that the default buffer size in io::copy is too small](https://github.com/BLAKE3-team/BLAKE3/blob/4108923f5284e0f8c3cf97b59041c2b6b2f601d3/b3sum/src/main.rs#L235-L239). With this optimization they could achieve the desired performance by wrapping the reader in a `BufReader` instead of handrolling it.
Currently the optimization doesn't apply to things like `StdinLock`, but this can be addressed with an additional `AsMutBufReader` specialization trait.
|
|
|
|
previously it was only able to use BufWriter. This was due to a limitation in the
BufReader generics that prevented specialization. This change works around the issue
by using `where Self: Read` instead of `where I: Read`. This limits our options, e.g.
we can't access BufRead methods, but it happens to work out if we rely on some
implementation details.
|
|
|
|
Simplify `ImplSource` candidates a bit
Reduce the number of impl source candidates, which will hopefully make our life easier when trying to adapt things like `SelectionContext::select` and `codegen_select_candidate` for the new solver.
r? `@lcnr` but feel free to reassign
|
|
|
|
|
|
|
