Rustup #16094
Merged
Rustup #16094
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
Constify trait aliases Allow `const trait Foo = Bar + [const] Baz;` trait alias declarations. Their rules are the same as with super traits of const traits. So `[const] Baz` or `const Baz` is only required for `[const] Foo` or `const Foo` bounds respectively. tracking issue rust-lang/rust#41517 (part of the general trait alias feature gate, but I can split it out into a separate const trait alias feature gate. I just assumed that const traits would stabilize before trait aliases, and we'd want to stabilize trait aliases together with const trait aliases at the same time) r? ``@compiler-errors`` ``@fee1-dead``
…,traviscross Implement pin-project in pattern matching for `&pin mut|const T` This PR implements part of rust-lang/rust#130494. It supports pin-project in pattern matching for `&pin mut|const T`. ~Pin-projection by field access (i.e. `&pin mut|const place.field`) is not fully supported yet since pinned-borrow is not ready (rust-lang/rust#135731).~ CC ``````@traviscross``````
Clippy subtree update r? ``@Manishearth`` Cargo.lock update due to Clippy version bump
…r=estebank fix: Only special case single line item attribute suggestions `rustc` currently special cases suggestions to add [`#[derive(_)]\n` and other attributes](https://github.com/rust-lang/rust/blob/dc1feabef242259d61bd930713de3250577c1c71/compiler/rustc_errors/src/emitter.rs#L2288C36-L2288C72), to add more context to the suggestions. > // The suggestion adds an entire line of code, ending on a newline, so we'll also > // print the *following* line, to provide context of what we're advising people to > // do. Otherwise you would only see contextless code that can be confused for > // already existing code, despite the colors and UI elements. > // We special case `#[derive(_)]\n` and other attribute suggestions, because those > // are the ones where context is most useful. This special case is a bit broad at the moment and applies to suggestions just to add an attribute, as well as suggestions that contain an attribute and other code, i.e. ```rust #[derive(Clone)] ``` and ```rust #[cfg(not(test))] impl Default for NewWithCfg { fn default() -> Self { Self::new() } } ``` In the latter case, adding a line for context after the suggestion doesn't provide much benefit. Example:  This PR makes it so that this special case only applies to suggestions that just add an attribute and nothing else. This will also make `rustc`'s output match `annotate-snippets`.
When mgca is enabled, const rhs's that are paths may have false negatives with the lints in non_copy_const.rs. But these should probably be using the trait solver anyway, and it only happens under mgca.
mgca: Add ConstArg representation for const items tracking issue: rust-lang/rust#132980 fixes rust-lang/rust#131046 fixes rust-lang/rust#134641 As part of implementing `min_generic_const_args`, we need to distinguish const items that can be used in the type system, such as in associated const equality projections, from const items containing arbitrary const code, which must be kept out of the type system. Specifically, all "type consts" must be either concrete (no generics) or generic with a trivial expression like `N` or a path to another type const item. To syntactically distinguish these cases, we require, for now at least, that users annotate all type consts with the `#[type_const]` attribute. Then, we validate that the const's right-hand side is indeed eligible to be a type const and represent it differently in the HIR. We accomplish this representation using a new `ConstItemRhs` enum in the HIR, and a similar but simpler enum in the AST. When `#[type_const]` is **not** applied to a const (e.g. on stable), we represent const item right-hand sides (rhs's) as HIR bodies, like before. However, when the attribute is applied, we instead lower to a `hir::ConstArg`. This syntactically distinguishes between trivial const args (paths) and arbitrary expressions, which are represented using `AnonConst`s. Then in `generics_of`, we can take advantage of the existing machinery to bar the `AnonConst` rhs's from using parent generics.
Add `overflow_checks` intrinsic This adds an intrinsic which allows code in a pre-built library to inherit the overflow checks option from a crate depending on it. This enables code in the standard library to explicitly change behavior based on whether `overflow_checks` are enabled, regardless of the setting used when standard library was compiled. This is very similar to the `ub_checks` intrinsic, and refactors the two to use a common mechanism. The primary use case for this is to allow the new `RangeFrom` iterator to yield the maximum element before overflowing, as requested [here](rust-lang/rust#125687 (comment)). This PR includes a working `IterRangeFrom` implementation based on this new intrinsic that exhibits the desired behavior. [Prior discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/Ability.20to.20select.20code.20based.20on.20.60overflow_checks.60.3F)
…=urgau
Add new `function_casts_as_integer` lint
The `function_casts_as_integer` lint detects cases where users cast a function pointer into an integer.
*warn-by-default*
### Example
```rust
fn foo() {}
let x = foo as usize;
```
```
warning: casting a function into an integer implicitly
--> $DIR/function_casts_as_integer.rs:9:17
|
LL | let x = foo as usize;
| ^^^^^^^^
|
help: add `fn() as usize`
|
LL | let x = foo as fn() as usize;
| +++++++
```
### Explanation
You should never cast a function directly into an integer but go through a cast as `fn` first to make it obvious what's going on. It also allows to prevent confusion with (associated) constants.
Related to rust-lang/rust#81686 and https://stackoverflow.com/questions/68701177/whats-the-meaning-of-casting-a-rust-enum-variant-to-a-numeric-data-type
r? ````@urgau````
Using the new `override_allocator_on_supported_platforms` feature in `tikv-jemalloc-sys v0.6.1` we can avoid the manual statics.
rustbot
added
the
S-waiting-on-review
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
14 participants
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.
r? @ghost
changelog: none