Automatic Rustup #3269
Closed
Automatic Rustup #3269
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
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Suggest quoting unquoted idents in attrs Closes #58462
Fix ICE when suggesting dereferencing binop operands Fixes #119352
…Mark-Simulacrum Update compiler_builtins to 0.1.105 This provides the builtins for the hexagon architecture.
Exhaustiveness: remove the need for arena-allocation within the algorithm After rust-lang/rust#119688, exhaustiveness checking doesn't need access to the arena anymore. This simplifies the lifetime story and makes it compile on stable without the extra dependency. r? `@compiler-errors`
Tune the inlinability of `unwrap` Fixes #115463 cc `@thomcc` This tweaks `unwrap` on ~~`Option` &~~ `Result` to be two parts: - `#[inline(always)]` for checking the discriminant - `#[cold]` for actually panicking The idea here is that checking the discriminant on a `Result` ~~or `Option`~~ should always be trivial enough to be worth inlining, even in `opt-level=z`, especially compared to passing it to a function. As seen in the issue and codegen test, this will hopefully help particularly for things like `.try_into().unwrap()`s that are actually infallible, but in a way that's only visible with the inlining. EDIT: I've restricted this to `Result` to avoid combining effects
…errors never patterns: Check bindings wrt never patterns Never patterns: - Shouldn't contain bindings since they never match anything; - Don't count when checking that or-patterns have consistent bindings. r? `@compiler-errors`
Avoid some redundant work in GVN The first 2 commits are about reducing the perf effect. Third commit avoids doing redundant work: is a local is SSA, it already has been simplified, and the resulting value is in `self.locals`. No need to call any code on it. The last commit avoids removing some storage statements. r? wg-mir-opt
Sandwich MIR optimizations between DSE. This PR reorders MIR optimization passes in an attempt to increase their efficiency. - Stop running CopyProp before GVN, it's useless as GVN will do the same thing anyway. Instead, we perform CopyProp at the end of the pipeline, to ensure we do not emit copy/move chains. - Run DSE before GVN, as it increases the probability to have single-assignment locals. - Run DSE after the final CopyProp to turn copies into moves. r? `@ghost`
Split out `option::unwrap_failed` like we have `result::unwrap_failed` ...and like `option::expect_failed`
Update measureme crate to version 11 perf.rlo has been updated to use 11.0.0 already, so it should be able to handle the new file format. r? `@Mark-Simulacrum` Fixes rust-lang/rust#99282 Fixes rust-lang/rust#119103
Fold arithmetic identities in GVN Extracted from rust-lang/rust#111344 This PR implements a few arithmetic folds for unary and binary operations. This should take care of the missed optimizations introduced by rust-lang/rust#116012.
…etrochenkov Add way to express that no values are expected with check-cfg This PR adds way to express no-values (no values expected) with `--check-cfg` by making empty `values()` no longer mean `values(none())` (internal: `&[None]`) and now be an empty list (internal: `&[]`). ### Context Currently `--check-cfg` has a way to express that _any value is expected_ with `values(any())`, but has no way to do the inverse and say that _no value is expected_. This would be particularly useful for build systems that control a config name and it's values as they could always declare a config name as expected and if in the current state they have values pass them and if not pass an empty list. To give a more concrete example, Cargo `--check-cfg` currently needs to generate: - `--check-cfg=cfg(feature, values(...))` for the case with declared features - and `--check-cfg=cfg()` for the case without any features declared This means that when there are no features declared, users will get an `unexpected config name` but from the point of view of Cargo the config name `feature` is expected, it's just that for now there aren't any values for it. See [Cargo `check_cfg_args` function](https://github.com/rust-lang/cargo/blob/92395d90106b3b61bcb68bcf2069052c93771764/src/cargo/core/compiler/mod.rs#L1263-L1281) for more details. ### De-specializing *empty* `values()` To solve this issue I propose that we "de-specialize" empty `values()` to no longer mean `values(none())` but to actually mean empty set/list. This is one of the last source of confusion for my-self and others with the `--check-cfg` syntax. > The confusing part here is that an empty `values()` currently means the same as `values(none())`, i.e. an expected list of values with the _none_ variant (as in `#[cfg(name)]` where the value is none) instead of meaning an empty set. Before the new `cfg()` syntax, defining the _none_ variant was only possible under certain circumstances, so in rust-lang/rust#111068 I decided to make `values()` to mean the _none_ variant, but it is no longer necessary since rust-lang/rust#119473 which introduced the `none()` syntax. A simplified representation of the proposed "de-specialization" would be: | Syntax | List/set of expected values | |-----------------------------------------|-----------------------------| | `cfg(name)`/`cfg(name, values(none()))` | `&[None]` | | `cfg(name, values())` | `&[]` | Note that I have my-self made the mistake of using an empty `values()` as meaning empty set, see rust-lang/cargo#13011. `@rustbot` label +F-check-cfg r? `@petrochenkov` cc `@epage`
…imulacrum tests: add sanity-check assembly test for every target Fixes #119910. Adds a basic assembly test checking that each target can produce assembly and update the target tier policy to require this. cc rust-lang/compiler-team#655 r? `@wesleywiser`
|
CI failed because of rust-lang/cargo#13311, we don't need an update. |
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.
No description provided.