| Age | Commit message (Collapse) | Author | Lines |
|
r=Mark-Simulacrum
Add test for eval order for a+=b
Yes, the order of evaluation *does* change depending on the types of
the operands. Cursed, I know.
I've elected to place this test into `expr/compound-assignment` creating
both the `expr` directory and the `compound-assignment` directory. I
plan in a future PR to also move the `if` directory and the loose `if`
tests into `expr/if` and other similar cleanups of the `test/ui`
directory.
Future work: Test more than just `+=`, but all operators. I don't know
if using a macro to generate these tests cases would be okay or not,
but it'd be boilerplatey without it. I'm also confident you cannot
change the evaluation order of one operator without changing all of
them.
Future work: Additionally, test more than just `i32 += i32` for the
primitive version. I don't actually know the full set of primitive
implementations, but I imagine there's enough to cause a combinatorial
explosion with the previous future work item. Somewhere on the order of
one to two hundred individual functions.
|
|
Split each iterator adapter and source into individual modules
This PR creates individual modules for each iterator adapter and iterator source.
This is done to enhance the readability of corresponding modules (`adapters/mod.rs` and `sources.rs`) which were hard to navigate and read because of lots of repeated lines (e.g.: `adapters/mod.rs` was 3k lines long). This is also in line with some adapters which already had their own modules (`Flatten`, `FlatMap`, `Chain`, `Zip`, `Fuse`).
This PR also makes `Take`s adapter fields private (I have no idea why they were `pub(super)` before).
r? ``@LukasKalbertodt``
|
|
Consolidate exhaustiveness-related tests
I hunted for tests that only exercised the match exhaustiveness algorithm and regrouped them. I also improved integer-range tests since I had found them lacking while hacking around.
The interest is mainly so that one can pass `--test-args patterns` and catch most relevant tests.
r? `@varkor`
`@rustbot` modify labels: +A-exhaustiveness-checking
|
|
Add regression test for issue 73899
Closes #73899
|
|
Adds regression test for https://github.com/rust-lang/rust/issues/73899
|
|
Yes, the order of evaluation *does* change depending on the types of
the operands. Cursed, I know.
I've elected to place this test into `expr/compound-assignment` creating
both the `expr` directory and the `compound-assignment` directory. I
plan in a future PR to also move the `if` directory and the loose `if`
tests into `expr/if` and other similar cleanups of the `test/ui`
directory.
Future work: Test more than just `+=`, but all operators. I don't know
if using a macro to generate these tests cases would be okay or not,
but it'd be boilerplatey without it. I'm also confident you cannot
change the evaluation order of one operator without changing all of
them.
Future work: Additionally, test more than just `i32 += i32` for the
primitive version. I don't actually know the full set of primitive
implementations, but I imagine there's enough to cause a combinatorial
explosion with the previous future work item. Somewhere on the order of
one to two hundred individual functions.
|
|
Some UI tests started failing after moving iterator adapters to different modules.
|
|
Add support for custom allocators in `Vec`
This follows the [roadmap](https://github.com/rust-lang/wg-allocators/issues/7) of the allocator WG to add custom allocators to collections.
r? `@Amanieu`
This pull request requires a crater run.
### Prior work:
- #71873: Crater-test to solve rust-lang/wg-allocators#1
- [`alloc-wg`](https://github.com/TimDiekmann/alloc-wg)-crate
|
|
Support building clone shims for arrays with generic size
Fixes #79269.
|
|
Exhaustively match in variant count instrinsic
Fix #79137
|
|
lint: Do not provide suggestions for non standard characters
Fixes #77273
Only provide suggestions if the case-fixed result is different than the original.
|
|
|
|
|
|
|
|
|
|
|
|
Add lint for panic!("{}")
This adds a lint that warns about `panic!("{}")`.
`panic!(msg)` invocations with a single argument use their argument as panic payload literally, without using it as a format string. The same holds for `assert!(expr, msg)`.
This lints checks if `msg` is a string literal (after expansion), and warns in case it contained braces. It suggests to insert `"{}", ` to use the message literally, or to add arguments to use it as a format string.

This lint is also a good starting point for adding warnings about `panic!(not_a_string)` later, once [`panic_any()`](https://github.com/rust-lang/rust/pull/74622) becomes a stable alternative.
|
|
Revert #78969 "Normalize function type during validation"
Closes #79066.
Reopens #78442.
|
|
expand/resolve: Pre-requisites to "Turn `#[derive]` into a regular macro attribute"
Miscellaneous refactorings and error reporting changes extracted from https://github.com/rust-lang/rust/pull/79078.
Unlike https://github.com/rust-lang/rust/pull/79078 this PR doesn't make any observable changes to the language or library.
r? ```@Aaron1011```
|
|
Test drop order for (destructuring) assignments
Add a test that checks whether the drop order of `let` bindings is consistent with the drop order of the corresponding destructuring assignments.
Thanks to ```@RalfJung``` for the suggesting this test ([here](https://github.com/rust-lang/rust/pull/79016#issuecomment-727608732)) and an implementation!
r? ```@RalfJung```
|
|
|
|
Collect derive placeholders using `collect` instead of `push`
|
|
|
|
|
|
r=petrochenkov
Permit standalone generic parameters as const generic arguments in macros
Fixes https://github.com/rust-lang/rust/issues/79127.
r? ```@petrochenkov```
|
|
add optimization fuel checks to some mir passes
Fixes #77402
Inserts a bunch of calls to `consider_optimizing`. Note that `consider_optimizing` is the method that actually decrements the fuel count, so the point at which it's called is when the optimization takes place, from a fuel perspective. This means that where we call it has some thought behind it:
1. We probably don't want to decrement the fuel count before other simple checks, otherwise we count an optimization as being performed even if nothing was mutated (ie. it returned early).
2. In cases like `InstCombine`, where we gather optimizations in a pass and then mutate values, we probably would rather skip the gathering pass for performance reasons rather than skip the mutations afterwards.
|
|
Remove redundant notes in E0275
Fix #58964.
|
|
Add two regression tests
For #78721 and #78722
|
|
Improve the diagnostic for when an `fn` contains qualifiers inside an `extern` block.
This mitigates #78941. As suggested by ```@estebank,``` `span_suggestion` was replaced with `span_suggestion_verbose` for this specific diagnostic.
|
|
Make bad "rust-call" arguments no longer ICE
The simplest of bad rust-call definitions will no longer cause an ICE. There is a FIXME added for future work, as I wanted to get this easy fix in before trying to either add a hack or mess with the whole obligation system
fixes #22565
|
|
|
|
This reverts commit d486bfcbff107e8a6769e00c59d02b13c664b6ee.
|
|
Handle empty matches cleanly in exhaustiveness checking
This removes the special-casing of empty matches that was done in `check_match`. This fixes most of https://github.com/rust-lang/rust/issues/55123.
Somewhat unrelatedly, I also made `_match.rs` more self-contained, because I think it's cleaner.
r? `@varkor`
`@rustbot` modify labels: +A-exhaustiveness-checking
|
|
|
|
As `Cell` won't receive an allocator parameter, it is used. Otherwise a `#![feature(allocator_api)]` could have been added, but for the purpose of this test, changing the type is more clear.
|
|
|
|
|
|
Fix #58964.
|
|
|
|
type is too big -> values of the type are too big
strictly speaking, `[u8; usize::MAX]` or even `[[[u128; usize::MAX]; usize::MAX]; usize::MAX]` are absolutely fine types as long as you don't try to deal with any values of it.
This error message seems to cause some confusion imo, for example in https://github.com/rust-lang/rust/pull/79135#issuecomment-729361380 so I would prefer us to be more precise here.
See the added test case which uses one of these types without causing an error.
r? ``@oli-obk``
|
|
stability: More precise location for deprecation lint on macros
One missing piece of https://github.com/rust-lang/rust/pull/73178.
|
|
level flag to test
|
|
|
|
|
|
|
|
|
|
extend macro braces test
r? `@varkor`
|
|
Fix exhaustiveness in case a byte string literal is used at slice type
fixes #79048
|
|
|
|
|