| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #119158 (Clean up alloc::sync::Weak Clone implementation)
- #119386 (fix typo in `IpAddr::to_canonical`)
- #119413 (solaris support on bootstrap lock)
- #119424 (Primitive docs: fix confusing `Send` in `&T`'s list)
- #119425 (Fix invalid check-cfg Cargo feature diagnostic help)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix invalid check-cfg Cargo feature diagnostic help
#118213 added specialized diagnostic for Cargo `feature` cfg. However when providing an empty `#[cfg(feature)]` condition the suggestion would suggest adding `feature` as a feature in `Cargo.toml` (wtf!).
This PR removes the invalid logic, which even brings a nice improvement.
```diff
--> $DIR/cargo-feature.rs:18:7
|
LL | #[cfg(feature)]
- | ^^^^^^^
+ | ^^^^^^^- help: specify a config value: `= "bitcode"`
|
= note: expected values for `feature` are: `bitcode`
- = help: consider defining `feature` as feature in `Cargo.toml`
```
The first commit add a test showing the bug and the second commit fixes the bug.
`@rustbot` label +F-check-cfg
|
|
Primitive docs: fix confusing `Send` in `&T`'s list
The two lists in this document describe what traits are implemented on references when their underlying `T` also implements them. However, while it is true that `T: Send + Sync` implies `&T: Send` (which is what the sentence is trying to explain), it is confusing to have `Send` in the list because `T: Send` is not needed for that. In particular, the "also require" part may be interpreted as "both `T: Send` and `T: Sync` are required".
Instead, move `Send` back to where it was before commit 7a477869b72e ("Makes docs for references a little less confusing"), i.e. to the `&mut` list (where no extra nota is needed, i.e. it fits naturally) and move the `Sync` definition/note to the bottom as something independent.
|
|
solaris support on bootstrap lock
With https://github.com/yoshuawuyts/fd-lock/pull/48, `fd-lock` now supports Solaris. Therefore we no longer need to conditionally handle the bootstrap locks.
|
|
fix typo in `IpAddr::to_canonical`
|
|
Clean up alloc::sync::Weak Clone implementation
Since both return points (tail and early return) return the same expression and the only difference is whether inner is available, the code that does the atomic operations and checks on inner was moved into the if body and the only return is at the tail. Original comments preserved.
|
|
Don't validate / lint MIR before each pass
To avoid redundant work and verbose output in case of failures.
|
|
Change `rustc_codegen_ssa`'s `atomic_cmpxchg` interface to return a pair of values
Doesn't change much, but a little nicer that way.
|
|
Shrink span encoding further
Spans are now stored in a more compact form which cuts down on at least 1 byte per span (indirect/direct encoding) and at most 3 bytes per span (indirect/direct encoding, context byte, length byte). As a result, libcore metadata shrinks by 1.5MB.
I'm not a huge fan of the fairly manual encoding/decoding from bits implemented here. Something like Tokio's pack abstraction (https://github.com/tokio-rs/tokio/blob/master/tokio/src/util/bit.rs) might be desirable to cut down on some of the shifting etc. We might also say that this isn't worth doing :)
I took a look at copying the span encoding we use in memory (described [here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_span/src/span_encoding.rs)). I think the format there makes a lot more sense for in-memory storage where prioritizing a fixed length (i.e., 4 or 8 bytes) is much more important. In metadata, it's much easier for us to have variable-length values, so there's less of a cliff if we don't quite fit. The bit packing scheme there would need changes to fit the varint scheme since it has a lot of all-1s patterns as the "relative offset" form.
|
|
Implement constant propagation on top of MIR SSA analysis
This implements the idea I proposed in https://github.com/rust-lang/rust/pull/110719#issuecomment-1718324700
Based on https://github.com/rust-lang/rust/pull/109597
The value numbering "GVN" pass formulates each rvalue that appears in MIR with an abstract form (the `Value` enum), and assigns an integer `VnIndex` to each. This abstract form can be used to deduplicate values, reusing an earlier local that holds the same value instead of recomputing. This part is proposed in #109597.
From this abstract representation, we can perform more involved simplifications, for example in https://github.com/rust-lang/rust/pull/111344.
With the abstract representation `Value`, we can also attempt to evaluate each to a constant using the interpreter. This builds a `VnIndex -> OpTy` map. From this map, we can opportunistically replace an operand or a rvalue with a constant if their value has an associated `OpTy`.
The most relevant commit is [Evaluated computed values to constants.](https://github.com/rust-lang/rust/commit/2767c4912ea249c2f613a9cedcd6c13ea1237e54)"
r? `@oli-obk`
|
|
Spans are now stored in a more compact form which cuts down on at least
1 byte per span (indirect/direct encoding) and at most 3 bytes per span
(indirect/direct encoding, context byte, length byte). As a result,
libcore metadata shrinks by 1.5MB.
|
|
Rollup of 5 pull requests
Successful merges:
- #119322 (Couple of random coroutine pass simplifications)
- #119374 (Italicise "bytes" in the docs of some `Vec` methods)
- #119388 (rustc_lint: Prevent triplication of various lints)
- #119406 (Add non-regression test for ATPIT ICE #114325)
- #119410 (Rename test to be more descriptive)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
The two lists in this document describe what traits are implemented on
references when their underlying `T` also implements them. However,
while it is true that `T: Send + Sync` implies `&T: Send` (which is
what the sentence is trying to explain), it is confusing to have `Send`
in the list because `T: Send` is not needed for that. In particular,
the "also require" part may be interpreted as "both `T: Send` and
`T: Sync` are required".
Instead, move `Send` back to where it was before commit 7a477869b72e
("Makes docs for references a little less confusing"), i.e. to the `&mut`
list (where no extra nota is needed, i.e. it fits naturally) and move the
`Sync` definition/note to the bottom as something independent.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Rename test to be more descriptive
As suggested in https://github.com/rust-lang/rust/pull/119402#discussion_r1438171079
r? ``@Nilstrieb``
|
|
Add non-regression test for ATPIT ICE #114325
ATPIT issue #114325 had been unknowingly fixed by https://github.com/rust-lang/rust/pull/107421, so this PR adds its [MCVE](https://github.com/rust-lang/rust/issues/114325#issuecomment-1721561552) as a non-regression test.
Closes #114325.
|
|
rustc_lint: Prevent triplication of various lints
Prevent triplication of various lints. The triplication happens because we run the same lint three times (or less in some cases):
* In `BuiltinCombinedPreExpansionLintPass`
* In `BuiltinCombinedEarlyLintPass`
* In `shallow_lint_levels_on()`
Only run the lints one time by checking the `lint_added_lints` bool.
Set your GitHub diff setting to ignore whitespaces changes when reviewing this PR, since I had to enclose a block inside an if.
Closes #73301
(I found this while exploring the code related to [this](https://github.com/rust-lang/rust/pull/119251#discussion_r1435677330) comment.)
|
|
Italicise "bytes" in the docs of some `Vec` methods
On a cursory read it's easy to miss that the limit is in terms of bytes not no. of elements. The italics should help with that.
Fixes #119149
|
|
Couple of random coroutine pass simplifications
Just aesthetic changes, except for a random `Ty::new_task_context(tcx)` call that was redundant.
|
|
fix: correct the args for `disambiguate the associated function` diagnostic
This is somehow silimar to https://github.com/rust-lang/rust/pull/118502, we shouldn't take receiver as first arg all the cases.
close https://github.com/rust-lang/rust/issues/118819
|
|
Remove usage of deprecated `missing-tools` bootstrap flag
This PR removes the usage of `--enable-missing-tools` in CI, as this config option is no longer used. It also removes `dist.missing-tools` config completely.
Let me know which commits should I remove (if any).
Fixes: https://github.com/rust-lang/rust/issues/79249
r? `@onur-ozkan`
|
|
Only store StableCrateId once in DefPathTable.
https://github.com/rust-lang/rust/pull/119238 made me think of this.
cc `@Mark-Simulacrum`
|
|
|
|
Clippy subtree update
r? `@Manishearth`
|
|
Rollup of 5 pull requests
Successful merges:
- #119375 (Merge Coroutine lowering functions)
- #119393 (Use filter instead of filter_map in Parser::expected_one_of_not_found)
- #119401 (coverage: Avoid a possible query stability hazard in `CoverageCounters`)
- #119402 (Also walk bindings created by if-let guards)
- #119404 (Enable profiler in dist-powerpc-linux)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Enable profiler in dist-powerpc-linux
|
|
Also walk bindings created by if-let guards
This change makes the `unused_variables` lint pick up unused bindings created by if-let guards.
Fixes #119383
|
|
coverage: Avoid a possible query stability hazard in `CoverageCounters`
#119252 revealed a possible query stability hazard in `CoverageCounters`: we iterate over the entries of an `FxHashMap` in a way that allows the iteration order to potentially affect the relative creation order of MIR blocks.
I'm not sure whether there's an actual stability problem or not in practice, but it's certainly a hazard, and I don't see any reason not to switch over to `FxIndexMap` to avoid potential issues.
---
This can either be merged on its own, or incorporated into #119252.
cc `@Enselic`
r? `@cjgillot`
|
|
Use filter instead of filter_map in Parser::expected_one_of_not_found
|
|
Merge Coroutine lowering functions
Instead of having separate `make_async/etc_expr` functions, this merges them them into one, reducing code duplication a bit.
|
|
|
|
|
|
because on a cursory read it's easy to miss that the limit is
in terms of bytes not no. of elements. The italics should help
with that.
|
|
make `ClosureArgsParts` and `CoroutineArgsParts` not generic
I hope a few extra calls to `expect_ty` will not affect perf...
|
|
|
|
Use `Pat::walk_always` instead of manual walk
It's also a bit faster, but I doubt that it will have a noticeable perf impact. Mostly doing it because it's shorter and nicer.
|
|
The iteration order of this hashmap can potentially affect the relative
creation order of MIR blocks.
|
|
|
|
utilize the unused `llvm-tools` option
This field was not functioning as described in its comment in `config.example.toml`. Also, updated the default value to `true` to keep the bootstrapping behavior as it was before.
cc `@Zalathar`
|
|
|
|
Remove movability from `TyKind::Coroutine`
There's no reason to store movability in the generator struct directly. It is computed from the HIR, and can be pulled into a query to access when necessary.
|
|
Instead of having separate `make_async/etc_expr` functions, this merges them them into one, reducing code duplication a bit.
|
|
|
|
|
|
|
|
|
