Rustc pull update (old tooling) #2490
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Turn `stdarch` into a Josh subtree In a similar vein as rust-lang/rust#141229, this PR makes the `stdarch` repository a Josh subtree (it was previously a submodule). The initial commit of `stdarch` upon this is based is `5a7342fc16b208b1b16624e886937ed8509a6506`, which is the previous commit SHA of the `stdarch` submodule. The sync was performed according to https://hackmd.io/7pOuxnkdQDaL1Y1FQr65xg. This was decided in rust-lang/stdarch#1655. Test pull PR on my fork: Kobzol/stdarch#1 Test push PR on my fork: Kobzol/rust#59 I plan to use the same Rust (miri-inspired) tooling that we use for `rustc-dev-guide` to enable pulls/pushes on stdarch. Note that this repository currently doesn't have any stdarch-specific tests, so before that, the subtree should only be modified through this repository only when dealing with changes that contain "cyclical dependencies" between stdarch and rustc. The long term vision is to integrate stdarch into rust-lang/rust completely. CC `@Amanieu` try-job: aarch64-apple try-job: aarch64-gnu try-job: `x86_64-msvc-*` try-job: x86_64-gnu try-job: x86_64-gnu-aux
Enforce in bootstrap that build must have stage at least 1 This PR is a step towards https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Proposal.20to.20cleanup.20stages.20and.20steps.20after.20the.20redesign/with/523586917. It's very hard or me to make self-contained changes to bootstrap at this moment, so this PR kind of does several things: 1) (first two commits) Try to reduce the usage of `Std::new` in bootstrap, and replace it with a `Builder::std` method (similar to `Builder::compiler`). This is mostly to remove executions of the `Std` step for stage 0, which doesn't make a lot of sense; I'd like to ideally have the invariant that when a step is invoked, it actually builds or does something. Eventually, I'd like for everything to go through `Builder::std`. (Note: I'm not totally married to this idea, if you don't like it, we can remove it from this PR. I mostly did it right now to remove stage 0 std steps from snapshot tests, which shouldn't be there, but we can also filter them out in a different way) 2) Make sure that when you pass `x build compiler`, only the `Assemble` root level step will be invoked, and not the `Rustc` step. Before, both were invoked, which actually ran `Rustc` twice, once with all `crates` filled, and once with no crates (but both actually represent the same situation). Since the `Rustc::make_run` step actually requests a compile that is one stage below it, this actually made `build compiler --stage 0` work, which we don't want to have anymore. 3) Enforce a bootstrap-global invariant that all `build` commands are always on stage `>=1`. If you try to `build` anything on stage 0, it will print a warning and exit bootstrap. This follows the intuition from the new staging rules after the stage redesign; artifacts that are "stage 0" come outside of bootstrap, and we can't really build something for which we don't have source (although we can still test it, but that's for another PR). Now the logic for build should be quite simple. For pretty much everything except for `Std`, you first use the stage0 compiler to build stage 1. Then you can build a stage 2 <something> using the previously built stage 1 (and then you can continue to stage 3 etc.). And that's it. The default build stage for everything is 1 (modulo download-ci-rustc, but that's a separate can of worms). The snapshot test infra isn't super nice at the moment, as one of next steps I want to create some simple Builder pattern that will allow us to configure the bootstrap invocations in a more "forward-compatible" way (e.g. now it's not possible to modify the config passed to `configure_with_args`). There are some things not yet fully resolved for build stage 0: 1) Cargo is still a `ModeRustc` tool, even though it doesn't really have to be, it is buildable with the stage0 compiler 2) bootstrap tools (`opt-dist`, `build-manifest` etc.) are still called stage0 tools, and in the bootstrap output it says something like "stage 0 rustc builds stage 0 opt-dist". Which is a bit weird, but functionally there's no difference, it's just a slightly inconsistent output. We still haven't decided if we should make these tools ignore staging altogether (which is IMO the right choice) or if we want to allow building stage 1/2/3/... bootstrap tools. r? `@jieyouxu` try-job: x86_64-rust-for-linux
…ead,WaffleLapkin Add edition checks for some tests that had divergent output In order to expose edition dependent divergences in some tests in the test suite, add explicit `edition` annotations. Some of these tests might require additional work to *avoid* the divergences, as they might have been unintentional. These are not exhaustive changes, purely opportunistic while I was looking at something else.
`evaluate_goal` avoid unnecessary step based on rust-lang/rust#142617. This does not mess with the debug logging for the trait solver and is a very nice cleanup for rust-lang/rust#142735. E.g. for ```rust #[derive(Clone)] struct Wrapper<T>(T); #[derive(Clone)] struct Nested; // using a separate type to avoid the fast paths fn is_clone<T: Clone>() {} fn main() { is_clone::<Wrapper<Nested>>(); } ``` We get the following proof tree with `RUSTC_LOG=rustc_type_ir::search_graph=debug,rustc_next_trait_solver=debug` ``` rustc_next_trait_solver::solve::eval_ctxt::evaluate_root_goal goal=Goal { param_env: ParamEnv { caller_bounds: [] }, predicate: Binder { value: TraitPredicate(<Wrapper<Nested> as std::clone::Clone>, polarity:Positive), bound_vars: [] } }, generate_proof_tree=No, span=src/main.rs:7:5: 7:34 (#0), stalled_on=None rustc_type_ir::search_graph::evaluate_goal input=CanonicalQueryInput { canonical: Canonical { value: QueryInput { goal: Goal { param_env: ParamEnv { caller_bounds: [] }, predicate: Binder { value: TraitPredicate(<Wrapper<Nested> as std::clone::Clone>, polarity:Positive), bound_vars: [] } }, predefined_opaques_in_body: PredefinedOpaques(PredefinedOpaquesData { opaque_types: [] }) }, max_universe: U0, variables: [] }, typing_mode: Analysis { defining_opaque_types_and_generators: [] } }, step_kind_from_parent=Unknown rustc_next_trait_solver::solve::eval_ctxt::probe::enter source=Impl(DefId(0:10 ~ main[21d2]::{impl#0})) rustc_next_trait_solver::solve::eval_ctxt::add_goal source=ImplWhereBound, goal=Goal { param_env: ParamEnv { caller_bounds: [] }, predicate: Binder { value: TraitPredicate(<_ as std::marker::Sized>, polarity:Positive), bound_vars: [] } } rustc_next_trait_solver::solve::eval_ctxt::add_goal source=ImplWhereBound, goal=Goal { param_env: ParamEnv { caller_bounds: [] }, predicate: Binder { value: TraitPredicate(<_ as std::clone::Clone>, polarity:Positive), bound_vars: [] } } rustc_type_ir::search_graph::evaluate_goal input=CanonicalQueryInput { canonical: Canonical { value: QueryInput { goal: Goal { param_env: ParamEnv { caller_bounds: [] }, predicate: Binder { value: TraitPredicate(<Nested as std::clone::Clone>, polarity:Positive), bound_vars: [] } }, predefined_opaques_in_body: PredefinedOpaques(PredefinedOpaquesData { opaque_types: [] }) }, max_universe: U0, variables: [] }, typing_mode: Analysis { defining_opaque_types_and_generators: [] } }, step_kind_from_parent=Unknown 0ms DEBUG rustc_type_ir::search_graph global cache hit, required_depth=0 0ms DEBUG rustc_type_ir::search_graph return=Ok(Canonical { value: Response { certainty: Yes, var_values: CanonicalVarValues { var_values: [] }, external_constraints: ExternalConstraints(ExternalConstraintsData { region_constraints: [], opaque_types: [], normalization_nested_goals: NestedNormalizationGoals([]) }) }, max_universe: U0, variables: [] }) rustc_next_trait_solver::solve::eval_ctxt::probe::enter source=BuiltinImpl(Misc) rustc_next_trait_solver::solve::trait_goals::merge_trait_candidates candidates=[Candidate { source: Impl(DefId(0:10 ~ main[21d2]::{impl#0})), result: Canonical { value: Response { certainty: Yes, var_values: CanonicalVarValues { var_values: [] }, external_constraints: ExternalConstraints(ExternalConstraintsData { region_constraints: [], opaque_types: [], normalization_nested_goals: NestedNormalizationGoals([]) }) }, max_universe: U0, variables: [] } }] 0ms DEBUG rustc_next_trait_solver::solve::trait_goals return=Ok((Canonical { value: Response { certainty: Yes, var_values: CanonicalVarValues { var_values: [] }, external_constraints: ExternalConstraints(ExternalConstraintsData { region_constraints: [], opaque_types: [], normalization_nested_goals: NestedNormalizationGoals([]) }) }, max_universe: U0, variables: [] }, Some(Misc))) 0ms DEBUG rustc_type_ir::search_graph insert global cache, evaluation_result=EvaluationResult { encountered_overflow: false, required_depth: 1, heads: CycleHeads { heads: {} }, nested_goals: NestedGoals { nested_goals: {} }, result: Ok(Canonical { value: Response { certainty: Yes, var_values: CanonicalVarValues { var_values: [] }, external_constraints: ExternalConstraints(ExternalConstraintsData { region_constraints: [], opaque_types: [], normalization_nested_goals: NestedNormalizationGoals([]) }) }, max_universe: U0, variables: [] }) } 0ms DEBUG rustc_type_ir::search_graph return=Ok(Canonical { value: Response { certainty: Yes, var_values: CanonicalVarValues { var_values: [] }, external_constraints: ExternalConstraints(ExternalConstraintsData { region_constraints: [], opaque_types: [], normalization_nested_goals: NestedNormalizationGoals([]) }) }, max_universe: U0, variables: [] }) ```
Fast path for WF goals in new solver Hopefully self-explanatory.
Stop collecting unmentioned constants This avoids generating useless dead LLVM IR. This appears to have regressed and/or been introduced in rust-lang/rust#53821 (unfortunately a very large PR - I don't see any direct discussion there of this particular change), but as far as I can tell is at least no longer necessary -- or we lack test coverage -- because none of our UI tests indicate diagnostics regressions. The adjusted codegen-units test has comments explicitly noting that these items should *not* be collected ("These are not referenced, so they do not produce mono-items"). I noticed this while looking at libcore LLVM IR we generate, which contained dead code references to the NOOP Waker item, which is never used inside libcore. Producing LLVM IR for it during libcore's compilation, only for that IR to get deleted by LLVM as unused, isn't useful. Note that the IR is generally all marked internal, too.
Insert checks for enum discriminants when debug assertions are enabled
Similar to the existing null-pointer and alignment checks, this checks for valid enum discriminants on creation of enums through unsafe transmutes. Essentially this sanitizes patterns like the following:
```rust
let val: MyEnum = unsafe { std::mem::transmute<u32, MyEnum>(42) };
```
An extension of this check will be done in a follow-up that explicitly sanitizes for extern enum values that come into Rust from e.g. C/C++.
This check is similar to Miri's capabilities of checking for valid construction of enum values.
This PR is inspired by saethlin@'s PR
rust-lang/rust#104862. Thank you so much for keeping this code up and the detailed comments!
I also pair-programmed large parts of this together with vabr-g@.
r? `@saethlin`
Don't fold in Instantiate when there's nothing to fold Maybe this helps idk r? lcnr
Only compute recursive callees once. Inlining MIR in a cyclic call graph may create query cycles, which are ICEs. The current implementation `mir_callgraph_reachable(inlining_candidate, being_optimized)` checks if calling `inlining_candidate` may cycle back to `being_optimized` that we are currently inlining into. This PR replaces this device with query `mir_callgraph_cyclic(being_optimized)` which searches the call graph for all cycles going back to `being_optimized`, and returns the set of functions involved in those cycles. This is a tradeoff: - in the current implementation, we perform more walks, but shallower; - in this new implementation, we perform fewer walks, but exhaust the graph. I'd have liked to compute this using some kind of SCC, but generic parameters make resolution path-dependent, so usual graph algorithms do not apply.
- Update ui.md - Update type-alias-impl-trait.md - Update README.md
Collapse Analysis|Borrowck|PostBorrowckAnalysis when there are no opaques r? lcnr
`tests/ui`: A New Order [13/N] Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895. r? ```@jieyouxu```
`tests/ui`: A New Order [15/N] > [!NOTE] > > Intermediate commits are intended to help review, but will be squashed prior to merge. Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895. r? `@jieyouxu`
fix typos and improve clarity in documentation ``` Description: This pull request corrects minor typos and improves wording for clarity across several documentation files, including: - Correcting instrinsics → intrinsics - Correcting preferrably → preferably - Correcting Orginally → Originally - Correcting resiliant → resilient ```
Add my work email to mailmap
Use the `new` method for `BasicBlockData` and `Statement` This is the NFC part of rust-lang/rust#142771. I split it to make it easier to review for rust-lang/rust#142771. Even without rust-lang/rust#142771, I think this change is worthwhile.
`tests/ui`: A New Order [17/N] > [!NOTE] > > Intermediate commits are intended to help review, but will be squashed prior to merge. Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895. r? `@tgross35`
Port #[link_section] to the new attribute parsing infrastructure Ports link_section to the new attribute parsing infrastructure for rust-lang/rust#131229 (comment) r? `@oli-obk` cc `@JonathanBrouwer` `@jdonszelmann`
Re-disable `tests/run-make/short-ice` on Windows MSVC again We tried to re-enable this for MSVC in rust-lang/rust#142844. Unfortunately, this test still sometimes fails on Windows MSVC. Tracked in rust-lang/rust#143198. FYI ```@dpaoliello``` (I couldn't reproduce this easily locally either)
Show auto trait and blanket impls for `!`
Add an empty `impl ! {}` so rustdoc shows auto trait impls and blanket impls on `!`'s documentation page.
This is already done for [unit](https://github.com/zachs18/rust/blob/2f0ad2a71e4a4528bb80bcb24bf8fa4e50cb87c2/library/core/src/primitive_docs.rs#L493), [tuples](https://github.com/zachs18/rust/blob/2f0ad2a71e4a4528bb80bcb24bf8fa4e50cb87c2/library/core/src/primitive_docs.rs#L1148), and [`fn` pointers](https://github.com/zachs18/rust/blob/2f0ad2a71e4a4528bb80bcb24bf8fa4e50cb87c2/library/core/src/primitive_docs.rs#L1874).
cc rust-lang/rust#97842 ``@notriddle`` which added the same for unit and tuple.
<details><summary>Comparison</summary>
[Before (current):](https://doc.rust-lang.org/nightly/std/primitive.never.html)
After:
</details>
``@rustbot`` label A-docs F-never_type
Rollup of 14 pull requests Successful merges: - rust-lang/rust#142429 (`tests/ui`: A New Order [13/N]) - rust-lang/rust#142514 (Miri: handling of SNaN inputs in `f*::pow` operations) - rust-lang/rust#143066 (Use let chains in the new solver) - rust-lang/rust#143090 (Workaround for memory unsafety in third party DLLs) - rust-lang/rust#143118 (`tests/ui`: A New Order [15/N]) - rust-lang/rust#143159 (Do not freshen `ReError`) - rust-lang/rust#143168 (`tests/ui`: A New Order [16/N]) - rust-lang/rust#143176 (fix typos and improve clarity in documentation) - rust-lang/rust#143187 (Add my work email to mailmap) - rust-lang/rust#143190 (Use the `new` method for `BasicBlockData` and `Statement`) - rust-lang/rust#143195 (`tests/ui`: A New Order [17/N]) - rust-lang/rust#143196 (Port #[link_section] to the new attribute parsing infrastructure) - rust-lang/rust#143199 (Re-disable `tests/run-make/short-ice` on Windows MSVC again) - rust-lang/rust#143219 (Show auto trait and blanket impls for `!`) r? `@ghost` `@rustbot` modify labels: rollup
…30, r=GuillaumeGomez GCC backend subtree update cc `@antoyo` r? ghost
Introduce `ByteSymbol` It's like `Symbol` but for byte strings. The interner is now used for both `Symbol` and `ByteSymbol`. E.g. if you intern `"dog"` and `b"dog"` you'll get a `Symbol` and a `ByteSymbol` with the same index and the characters will only be stored once. The motivation for this is to eliminate the `Arc`s in `ast::LitKind`, to make `ast::LitKind` impl `Copy`, and to avoid the need to arena-allocate `ast::LitKind` in HIR. The latter change reduces peak memory by a non-trivial amount on literal-heavy benchmarks such as `deep-vector` and `tuple-stress`. `Encoder`, `Decoder`, `SpanEncoder`, and `SpanDecoder` all get some changes so that they can handle normal strings and byte strings.
…i-obk Port `#[rustc_layout_scalar_valid_range_start/end]` to the new attrib… Ports `rustc_layout_scalar_valid_range_start` and `rustc_layout_scalar_valid_range_end` to the new attribute parsing infrastructure for rust-lang/rust#131229 (comment) r? `@jdonszelmann`
Split exported_symbols for generic and non-generic symbols This reduces metadata decoder overhead during the monomorphization collector.
Start moving wf checking away from HIR I'm trying to only access the HIR in the error path. My hope is that once we move significant portions of wfcheck off HIR that incremental will be able to cache wfcheck queries significantly better. I think I am reaching a blocker because we normally need to provide good spans to `ObligationCause`, so that the trait solver can report good errors. In some cases I have been able to use bad spans and improve them depending on the `ObligationCauseCode` (by loading HIR in the case where we actually want to error). To scale that further we'll likely need to remove spans from the `ObligationCause` entirely (leaving it to some variants of `ObligationCauseCode` to have a span when they can't recompute the information later). Unsure this is the right approach, but we've already been using it. I will create an MCP about it, but that should not affect this PR, which is fairly limited in where it does those kind of tricks. Especially rust-lang/rust@b862d88 is interesting here, because I think it improves spans in all cases
Add new self-profiling event to cheaply aggregate query cache hit counts Self-profile can record various types of things, some of them are not enabled, like query cache hits. Rustc currently records cache hits as "instant" measureme events, which records the thread ID, current timestamp, and constructs an individual event for each such cache hit. This is incredibly expensive, in a small hello world benchmark that just depends on serde, it makes compilation with nightly go from ~3s (with `-Zself-profile`) to ~15s (with `-Zself-profile -Zself-profile-events=default,query-cache-hit`). We'd like to add query cache hits to rustc-perf (rust-lang/rustc-perf#2168), but there we only need the actualy cache hit counts, not the timestamp/thread ID metadata associated with it. This PR adds a new `query-cache-hit-count` event. Instead of generating individual instant events, it simply aggregates cache hit counts per *query invocation* (so a combination of a query and its arguments, if I understand it correctly) using an atomic counter. At the end of the compilation session, these counts are then dumped to the self-profile log using integer events (in a similar fashion as how we record artifact sizes). I suppose that we could dedup the query invocations in rustc directly, but I don't think it's really required. In local experiments with the hello world + serde case, the query invocation records generated ~30 KiB more data in the self-profile, which was ~10% increase in this case. With this PR, the overhead of `-Zself-profile` seems to be the same as before, at least on my machine, so I also enabled query cache hit counts by default when self profiling is enabled. We should also modify `analyzeme`, specifically [this](https://github.com/rust-lang/measureme/blob/master/analyzeme/src/analysis.rs#L139), and make it load the integer events with query cache hit counts. I can do that as a follow-up, it's not required to be done in sync with this PR, and it doesn't require changes in rustc. CC `@cjgillot` r? `@oli-obk`
Rename `mingw-*` CI jobs to `pr-*` The name `mingw` confuses people because these CI jobs now do much more than just cross-compile to mingw. This is basically a find/replace. I chose the name `pr-` because it's job is to do general PR checks,
… r=GuillaumeGomez Lazy-ify some markdown rendering Seems to have a positive effect in my local perf runs 😍 r? `@GuillaumeGomez` if you're interested, otherwise feel free to reassign (would also love a perf run)
setup typos check in CI This allows to check typos in CI, currently for compiler only (to reduce commit size with fixes). With current setup, exclude list is quite short, so it worth trying? Also includes commits with actual typo fixes. MCP: rust-lang/compiler-team#817 typos check currently turned for: * ./compiler * ./library * ./src/bootstrap * ./src/librustdoc After merging, PRs which enables checks for other crates (tools) can be implemented too. Found typos will **not break** other jobs immediately: (tests, building compiler for perf run). Job will be marked as red on completion in ~ 20 secs, so you will not forget to fix it whenever you want, before merging pr. Check typos: `python x.py test tidy --extra-checks=spellcheck` Apply typo fixes: `python x.py test tidy --extra-checks=spellcheck:fix` (in case if there only 1 suggestion of each typo) Current fail in this pr is expected and shows how typo errors emitted. Commit with error will be removed after r+.
…i-obk Port `#[target_feature]` to new attribute parsing infrastructure Ports `target_feature` to the new attribute parsing infrastructure for rust-lang/rust#131229 (comment) r? ``@jdonszelmann``
…r=tgross35 avoid suggesting traits from private dependencies fixes rust-lang/rust#142676 fixes rust-lang/rust#138191 r? ``@tgross35``
Fix rustdoc not correctly showing attributes on re-exports Fixes attributes not being shown correctly in rustdoc on re-exports Does this need to be backported to beta? r? ``@jdonszelmann``
document optional jobs
…nted, r=jieyouxu minicore: use core's `diagnostic::on_unimplemented` messages Without these attributes, the error message is different. Keeping the diagnostics up-to-date seems related to rust-lang/rust#137531. The modified test files are reported in rust-lang/rust#143319 as failing for `--target=riscv64gc-unknown-linux-gnu`. Using `minicore` for them makes it easier to troubleshoot this sort of issue. r? ``@jieyouxu``
Rollup of 6 pull requests Successful merges: - rust-lang/rust#134006 (setup typos check in CI) - rust-lang/rust#142876 (Port `#[target_feature]` to new attribute parsing infrastructure) - rust-lang/rust#143038 (avoid suggesting traits from private dependencies) - rust-lang/rust#143083 (Fix rustdoc not correctly showing attributes on re-exports) - rust-lang/rust#143283 (document optional jobs) - rust-lang/rust#143329 (minicore: use core's `diagnostic::on_unimplemented` messages) Failed merges: - rust-lang/rust#143237 (Port `#[no_implicit_prelude]` to the new attribute parsing infrastructure) r? `@ghost` `@rustbot` modify labels: rollup
Weekly `cargo update`
Automation to keep dependencies in `Cargo.lock` current.
The following is the output from `cargo update`:
```txt
compiler & tools dependencies:
Locking 23 packages to latest compatible versions
Updating anstyle-svg v0.1.8 -> v0.1.9
Updating autocfg v1.4.0 -> v1.5.0
Updating bumpalo v3.18.1 -> v3.19.0
Updating derive-where v1.4.0 -> v1.5.0
Updating errno v0.3.12 -> v0.3.13
Updating indexmap v2.9.0 -> v2.10.0
Updating libredox v0.1.3 -> v0.1.4
Updating owo-colors v4.2.1 -> v4.2.2
Updating pest v2.8.0 -> v2.8.1
Updating pest_derive v2.8.0 -> v2.8.1
Updating pest_generator v2.8.0 -> v2.8.1
Updating pest_meta v2.8.0 -> v2.8.1
Updating r-efi v5.2.0 -> v5.3.0
Updating rustc-build-sysroot v0.5.8 -> v0.5.9
Updating slab v0.4.9 -> v0.4.10
Updating syn v2.0.103 -> v2.0.104
Adding toml v0.8.23
Adding toml_edit v0.22.27
Adding toml_write v0.1.2
Updating tracing-attributes v0.1.29 -> v0.1.30
Updating xattr v1.5.0 -> v1.5.1
Updating zerocopy v0.8.25 -> v0.8.26
Updating zerocopy-derive v0.8.25 -> v0.8.26
note: pass `--verbose` to see 39 unchanged dependencies behind latest
library dependencies:
Locking 0 packages to latest compatible versions
note: pass `--verbose` to see 3 unchanged dependencies behind latest
rustbook dependencies:
Locking 21 packages to latest compatible versions
Updating autocfg v1.4.0 -> v1.5.0
Updating bumpalo v3.18.1 -> v3.19.0
Updating errno v0.3.12 -> v0.3.13
Updating indexmap v2.9.0 -> v2.10.0
Updating markup5ever v0.16.1 -> v0.16.2
Updating pest v2.8.0 -> v2.8.1
Updating pest_derive v2.8.0 -> v2.8.1
Updating pest_generator v2.8.0 -> v2.8.1
Updating pest_meta v2.8.0 -> v2.8.1
Updating r-efi v5.2.0 -> v5.3.0
Updating syn v2.0.103 -> v2.0.104
Adding windows-sys v0.60.2
Adding windows-targets v0.53.2
Adding windows_aarch64_gnullvm v0.53.0
Adding windows_aarch64_msvc v0.53.0
Adding windows_i686_gnu v0.53.0
Adding windows_i686_gnullvm v0.53.0
Adding windows_i686_msvc v0.53.0
Adding windows_x86_64_gnu v0.53.0
Adding windows_x86_64_gnullvm v0.53.0
Adding windows_x86_64_msvc v0.53.0
```
MIR inliner maintains unused var_debug_info Only `full` debuginfo level promises variable-level debug information, but the MIR inline pass needlessly preserved the local variable debug info for the `limited` level too.
Add methods for converting bool to `Result<(), E>` ## Tracking Issue rust-lang/rust#142748 ## ACP rust-lang/libs-team#606
Fix `x clean` with a fifo `x clean` was failing when it encountered a special file like a fifo because it thought it was a directory.
Fast path nitpicks Miscellaneous commits that I didn't really want to fold into anything else. Fixes one theoretical bug with the fast path not considering polarity for `T: !Sized` bounds.
update coherence example ## PR Summary Small PR - Commit 0533ff7d4169692e05d11d219c287a477a5471bb moved the `coherence_different_hidden_ty.rs` file. This PR adjusts sources to changes.
use unsigned_abs instead of `abs` on signed int to silence clippy Use `unsigned_abs` instead of `abs` on signed int to silence clippy. Alternatively we could allow the lint, but if codegen is not affected, then this seems preferable.
remove redundant #[must_use]
Fixes these clippy warnings:
```
warning: this function has a `#[must_use]` attribute with no message, but returns a type already marked as `#[must_use]`
--> library/core/src/cmp.rs:1456:5
|
1456 | fn __chaining_lt(&self, other: &Rhs) -> ControlFlow<bool> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: either add some descriptive message or remove the attribute
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#double_must_use
= note: `-D clippy::double-must-use` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::double_must_use)]`
warning: this function has a `#[must_use]` attribute with no message, but returns a type already marked as `#[must_use]`
--> library/core/src/cmp.rs:1465:5
|
1465 | fn __chaining_le(&self, other: &Rhs) -> ControlFlow<bool> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: either add some descriptive message or remove the attribute
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#double_must_use
warning: this function has a `#[must_use]` attribute with no message, but returns a type already marked as `#[must_use]`
--> library/core/src/cmp.rs:1474:5
|
1474 | fn __chaining_gt(&self, other: &Rhs) -> ControlFlow<bool> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: either add some descriptive message or remove the attribute
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#double_must_use
warning: this function has a `#[must_use]` attribute with no message, but returns a type already marked as `#[must_use]`
--> library/core/src/cmp.rs:1483:5
|
1483 | fn __chaining_ge(&self, other: &Rhs) -> ControlFlow<bool> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: either add some descriptive message or remove the attribute
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#double_must_use
```
simplify receivers for some array method calls
Replace kw_span by full span for generic const parameters. Small simplification extracted from rust-lang/rust#127241
…laumeGomez rustdoc: don't treat methods under const impls or traits as const Fixes rust-lang/rust#143071
…ide-fn, r=compiler-errors compiler: Document and reduce `fn provide`s in hir crates I found it hard to follow all these tiny micro-indirections. Much like you shouldn't pass around `&u32` if you can help it, you probably shouldn't use an indirection if the indirection overhead itself is literally bigger than the amount of data you are organizing. Generally a new `fn provide` amounts to around 3 LOC: - the signature with opening brace - the `rustc_middle::query::Providers` import - an end brace I am not even counting the cost in time and thought to go find the other `provide`, read it, understand, "Ah, yes, these functions", and then go to those. Thus I say we should collapse indirections of `provide` for modules that only export 1~2 queries. For higher-count indirections, I left them as-is, as I don't understand the crate well enough to judge their worth. Then I dropped a pointer to the actual module of interest for all these instances of the same function. I think documenting them is important because the comment that it relates to the query system makes it obvious that they have **nothing** to do with the rest of the module's logic and I can carry on ignoring them. Actively doing so is another cognitive cost, but much more minimal. There is also a small correctness issue in that all of these functions are technically mutating state. It's not a huge deal, but it's still easier to check all these mutations do not overlap if we have less instances of `fn provide` to check.
…ss35
Always use the pure Rust fallback instead of `llvm.{maximum,minimum}`
While llvm/llvm-project#142170 was merged, it was reverted and next attempt (llvm/llvm-project#140193) at fixing the LLVM implementation seems to have stall, so let's reverted back to pure Rust with the LLVM codegen.
cc [#t-compiler/llvm > &rust-lang#96;llvm.minimum&rust-lang#96;/&rust-lang#96;llvm.maximum&rust-lang#96; issues @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/187780-t-compiler.2Fllvm/topic/.60llvm.2Eminimum.60.2F.60llvm.2Emaximum.60.20issues/near/527044712)
Fixes rust-lang/rust#141087
r? `@tgross35`
Rollup of 11 pull requests Successful merges: - rust-lang/rust#142749 (Add methods for converting bool to `Result<(), E>`) - rust-lang/rust#143288 (Fix `x clean` with a fifo) - rust-lang/rust#143307 (Fast path nitpicks) - rust-lang/rust#143346 (update coherence example) - rust-lang/rust#143356 (use unsigned_abs instead of `abs` on signed int to silence clippy) - rust-lang/rust#143370 (remove redundant #[must_use]) - rust-lang/rust#143378 (simplify receivers for some array method calls) - rust-lang/rust#143380 (Replace kw_span by full span for generic const parameters.) - rust-lang/rust#143381 (rustdoc: don't treat methods under const impls or traits as const) - rust-lang/rust#143394 (compiler: Document and reduce `fn provide`s in hir crates) - rust-lang/rust#143395 (Always use the pure Rust fallback instead of `llvm.{maximum,minimum}`) r? `@ghost` `@rustbot` modify labels: rollup
|
Looks good. |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Opening as a cross-check for #2489.