| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Do not ICE when we have `-Zunpretty=expanded` with invalid ABI
Fixes #99331
|
|
Do not constraint TAITs when checking impl/trait item compatibility
Check out the UI test for the example.
Open to other approaches to fix this issue -- ideally we _would_ be able to collect this opaque type constraint in a way to use it in `find_opaque_ty_constraints`, so we can report a better mismatch error in the incompatible case, and just allow it in the compatible case. But that seems like a bigger refactor, so I wouldn't want to start it unless someone else thought it was a good idea.
cc #99348
r? ``@oli-obk``
|
|
Be more precise when suggesting removal of parens on unit ctor
* Fixes #99240 by only suggesting to remove parens on path exprs, not arbitrary expressions with enum type
* Generalizes by suggesting removal of parens on unit struct, too, because why not?
|
|
The attribute is also renamed `fake_variadic`.
|
|
Use constant eval to do strict mem::uninit/zeroed validity checks
I'm not sure about the code organisation here, I just dumped the check in rustc_const_eval at the root. Not hard to move it elsewhere, in any case.
Also, this means cranelift codegen intrinsics lose the strict checks, since they don't seem to depend on rustc_const_eval, and I didn't see a point in keeping around two copies.
I also left comments in the is_zero_valid methods about "uhhh help how do i do this", those apply to both methods equally.
Also rustc_codegen_ssa now depends on rustc_const_eval... is this okay?
Pinging `@RalfJung` since you were the one who mentioned this to me, so I'm assuming you're interested.
Haven't had a chance to run full tests on this since it's really warm, and it's 1AM, I'll check out any failures/comments in the morning :)
|
|
|
|
|
|
rendering path
|
|
Add regression test for #95829
Closes #95829
r? `@compiler-errors`
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Add `#[test]` to functions in test modules
I implemented a suggestion in #91770, but the ui test I created was inadequate and I have fixed that.
|
|
Stabilize `let_chains` in Rust 1.64
# Stabilization proposal
This PR proposes the stabilization of `#![feature(let_chains)]` in a future-compatibility way that will allow the **possible** addition of the `EXPR is PAT` syntax.
Tracking issue: #53667
Version: 1.64 (beta => 2022-08-11, stable => 2022-10-22).
## What is stabilized
The ability to chain let expressions along side local variable declarations or ordinary conditional expressions. For example:
```rust
pub enum Color {
Blue,
Red,
Violet,
}
pub enum Flower {
Rose,
Tulip,
Violet,
}
pub fn roses_are_red_violets_are_blue_printer(
(first_flower, first_flower_color): (Flower, Color),
(second_flower, second_flower_color): (Flower, Color),
pick_up_lines: &[&str],
) {
if let Flower::Rose = first_flower
&& let Color::Red = first_flower_color
&& let Flower::Violet = second_flower
&& let Color::Blue = second_flower_color
&& let &[first_pick_up_line, ..] = pick_up_lines
{
println!("Roses are red, violets are blue, {}", first_pick_up_line);
}
}
fn main() {
roses_are_red_violets_are_blue_printer(
(Flower::Rose, Color::Red),
(Flower::Violet, Color::Blue),
&["sugar is sweet and so are you"],
);
}
```
## Motivation
The main motivation for this feature is improving readability, ergonomics and reducing paper cuts.
For more examples, see the [RFC](https://github.com/rust-lang/rfcs/blob/master/text/2497-if-let-chains.md).
## What isn't stabilized
* Let chains in match guards (`if_let_guard`)
* Resolution of divergent non-terminal matchers
* The `EXPR is PAT` syntax
## History
* On 2017-12-24, [RFC: if- and while-let-chains](https://github.com/rust-lang/rfcs/pull/2260)
* On 2018-07-12, [eRFC: if- and while-let-chains, take 2](https://github.com/rust-lang/rfcs/pull/2497)
* On 2018-08-24, [Tracking issue for eRFC 2497, "if- and while-let-chains, take 2](https://github.com/rust-lang/rust/issues/53667)
* On 2019-03-19, [Run branch cleanup after copy prop](https://github.com/rust-lang/rust/pull/59290)
* On 2019-03-26, [Generalize diagnostic for x = y where bool is the expected type](https://github.com/rust-lang/rust/pull/59439)
* On 2019-04-24, [Introduce hir::ExprKind::Use and employ in for loop desugaring](https://github.com/rust-lang/rust/pull/60225)
* On 2019-03-19, [[let_chains, 1/6] Remove hir::ExprKind::If](https://github.com/rust-lang/rust/pull/59288)
* On 2019-05-15, [[let_chains, 2/6] Introduce Let(..) in AST, remove IfLet + WhileLet and parse let chains](https://github.com/rust-lang/rust/pull/60861)
* On 2019-06-20, [[let_chains, 3/6] And then there was only Loop](https://github.com/rust-lang/rust/pull/61988)
* On 2020-11-22, [Reintroduce hir::ExprKind::If](https://github.com/rust-lang/rust/pull/79328)
* On 2020-12-24, [Introduce hir::ExprKind::Let - Take 2](https://github.com/rust-lang/rust/pull/80357)
* On 2021-02-19, [Lower condition of if expression before it's "then" block](https://github.com/rust-lang/rust/pull/82308)
* On 2021-09-01, [Fix drop handling for `if let` expressions](https://github.com/rust-lang/rust/pull/88572)
* On 2021-09-04, [Formally implement let chains](https://github.com/rust-lang/rust/pull/88642)
* On 2022-01-19, [Add tests to ensure that let_chains works with if_let_guard](https://github.com/rust-lang/rust/pull/93086)
* On 2022-01-18, [Introduce `enhanced_binary_op` feature](https://github.com/rust-lang/rust/pull/93049)
* On 2022-01-22, [Fix `let_chains` and `if_let_guard` feature flags](https://github.com/rust-lang/rust/pull/93213)
* On 2022-02-25, [Initiate the inner usage of `let_chains`](https://github.com/rust-lang/rust/pull/94376)
* On 2022-01-28, [[WIP] Introduce ast::StmtKind::LetElse to allow the usage of `let_else` with `let_chains`](https://github.com/rust-lang/rust/pull/93437)
* On 2022-02-26, [1 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94396)
* On 2022-02-26, [2 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94400)
* On 2022-02-27, [3 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94420)
* On 2022-02-28, [4 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94445)
* On 2022-02-28, [5 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94448)
* On 2022-02-28, [6 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94465)
* On 2022-03-01, [7 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94476)
* On 2022-03-01, [8 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94484)
* On 2022-03-01, [9 - Make more use of `let_chains`](https://github.com/rust-lang/rust/pull/94498)
* On 2022-03-08, [Warn users about `||` in let chain expressions](https://github.com/rust-lang/rust/pull/94754)
From the first RFC (2017-12-24) to the theoretical future stabilization day (2022-10-22), it can be said that this feature took 4 years, 9 months and 28 days of research, development, discussions, agreements and headaches to be settled.
## Divergent non-terminal matchers
More specifically, https://github.com/rust-lang/rust/issues/86730.
```rust
macro_rules! mac {
($e:expr) => {
if $e {
true
} else {
false
}
};
}
fn main() {
// OK!
assert_eq!(mac!(true && let 1 = 1), true);
// ERROR! Anything starting with `let` is not considered an expression
assert_eq!(mac!(let 1 = 1 && true), true);
}
```
To the best of my knowledge, such error or divergence is orthogonal, does not prevent stabilization and can be tackled independently in the near future or effectively in the next Rust 2024 edition. If not, then https://github.com/c410-f3r/rust/tree/let-macro-blah contains a set of changes that will consider `let` an expression.
It is possible that none of the solutions above satisfies all applicable constraints but I personally don't know of any other plausible answers.
## Alternative syntax
Taking into account the usefulness of this feature and the overwhelming desire to use both now and in the past, `let PAT = EXPR` will be utilized for stabilization but it doesn't or shall create any obstacle for a **possible** future addition of `EXPR is PAT`.
The introductory snippet would then be written as the following.
```rust
if first_flower is Flower::Rose
&& first_flower_color is Color::Red
&& second_flower is Flower::Violet
&& second_flower_color is Color::Blue
&& pick_up_lines is &[first_pick_up_line, ..]
{
println!("Roses are red, violets are blue, {}", first_pick_up_line);
}
```
Just to reinforce, this PR only unblocks a **possible** future road for `EXPR is PAT` and does emphasize what is better or what is worse.
## Tests
* [Verifies the drop order of let chains and ensures it won't change in the future in an unpredictable way](https://github.com/rust-lang/rust/blob/master/src/test/ui/mir/mir_let_chains_drop_order.rs)
* [AST lowering does not wrap let chains in an `DropTemps` expression](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/ast-lowering-does-not-wrap-let-chains.rs)
* [Checks pretty printing output](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/ast-pretty-check.rs)
* [Verifies uninitialized variables due to MIR modifications](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/chains-without-let.rs)
* [A collection of statements where `let` expressions are forbidden](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/disallowed-positions.rs)
* [All or at least most of the places where let chains are allowed](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/feature-gate.rs)
* [Ensures that irrefutable lets are allowed in let chains](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/irrefutable-lets.rs)
* [issue-88498.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-88498.rs), [issue-90722.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-90722.rs), [issue-92145.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-92145.rs) and [issue-93150.rs](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/issue-93150.rs) were bugs found by third parties and fixed overtime.
* [Indexing was triggering a ICE due to a wrongly constructed MIR graph](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/no-double-assigments.rs)
* [Protects the precedence of `&&` in relation to other things](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/protect-precedences.rs)
* [`let_chains`, as well as `if_let_guard`, has a valid MIR graph that evaluates conditional expressions correctly](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2497-if-let-chains/then-else-blocks.rs)
Most of the infra-structure used by let chains is also used by `if` expressions in stable compiler versions since https://github.com/rust-lang/rust/pull/80357 and https://github.com/rust-lang/rust/pull/88572. As a result, no bugs were found since the integration of https://github.com/rust-lang/rust/pull/88642.
## Possible future work
* Let chains in match guards is implemented and working but stabilization is blocked by `if_let_guard`.
* The usage of `let_chains` with `let_else` is possible but not implemented. Regardless, one attempt was introduced and closed in https://github.com/rust-lang/rust/pull/93437.
Thanks `@Centril` for creating the RFC and huge thanks (again) to `@matthewjasper` for all the reviews, mentoring and MIR implementations.
Fixes #53667
|
|
|
|
|
|
Fixes #99221
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Add a special case for align_offset /w stride != 1
This generalizes the previous `stride == 1` special case to apply to any
situation where the requested alignment is divisible by the stride. This
in turn allows the test case from #98809 produce ideal assembly, along
the lines of:
leaq 15(%rdi), %rax
andq $-16, %rax
This also produces pretty high quality code for situations where the
alignment of the input pointer isn’t known:
pub unsafe fn ptr_u32(slice: *const u32) -> *const u32 {
slice.offset(slice.align_offset(16) as isize)
}
// =>
movl %edi, %eax
andl $3, %eax
leaq 15(%rdi), %rcx
andq $-16, %rcx
subq %rdi, %rcx
shrq $2, %rcx
negq %rax
sbbq %rax, %rax
orq %rcx, %rax
leaq (%rdi,%rax,4), %rax
Here LLVM is smart enough to replace the `usize::MAX` special case with
a branch-less bitwise-OR approach, where the mask is constructed using
the neg and sbb instructions. This appears to work across various
architectures I’ve tried.
This change ends up introducing more branches and code in situations
where there is less knowledge of the arguments. For example when the
requested alignment is entirely unknown. This use-case was never really
a focus of this function, so I’m not particularly worried, especially
since llvm-mca is saying that the new code is still appreciably faster,
despite all the new branching.
Fixes #98809.
Sadly, this does not help with #72356.
|
|
|
|
|
|
|
|
This generalizes the previous `stride == 1` special case to apply to any
situation where the requested alignment is divisible by the stride. This
in turn allows the test case from #98809 produce ideal assembly, along
the lines of:
leaq 15(%rdi), %rax
andq $-16, %rax
This also produces pretty high quality code for situations where the
alignment of the input pointer isn’t known:
pub unsafe fn ptr_u32(slice: *const u32) -> *const u32 {
slice.offset(slice.align_offset(16) as isize)
}
// =>
movl %edi, %eax
andl $3, %eax
leaq 15(%rdi), %rcx
andq $-16, %rcx
subq %rdi, %rcx
shrq $2, %rcx
negq %rax
sbbq %rax, %rax
orq %rcx, %rax
leaq (%rdi,%rax,4), %rax
Here LLVM is smart enough to replace the `usize::MAX` special case with
a branch-less bitwise-OR approach, where the mask is constructed using
the neg and sbb instructions. This appears to work across various
architectures I’ve tried.
This change ends up introducing more branches and code in situations
where there is less knowledge of the arguments. For example when the
requested alignment is entirely unknown. This use-case was never really
a focus of this function, so I’m not particularly worried, especially
since llvm-mca is saying that the new code is still appreciably faster,
despite all the new branching.
Fixes #98809.
Sadly, this does not help with #72356.
|
|
|
|
Fix flakyness of GUI tests
Fixes #98163.
All flaky tests seemed to be linked to the search. Since the search JS is loaded when we focus the search input, I think it's possible that we enter faster than the JS is actually loaded. The solution for that would be to do it in two steps: first we write into the search input (`browser-ui-test` adds a small sleep time after such commands) and then we press enter to be sure that it wasn't missed.
cc `@JohnTitor`
r? `@Dylan-DPC`
|
|
Revert "Highlight conflicting param-env candidates"
This reverts #98794, commit 08135254dcf22be0d5661ea8f75e703b29a83514.
Seems to have caused an incremental compilation bug. The root cause of the incr comp bug is somewhat unrelated but is triggered by this PR, so I don't feel comfortable with having this PR in the codebase until it can be investigated further. Fixes #99233.
|
|
[rustdoc-json] JSON no longer inlines
Fixes #98007.
Fixes #96161.
Fixes https://github.com/rust-lang/rust/issues/83057.
Fixes https://github.com/rust-lang/rust/issues/83720.
I took over #93518 and applied the comments and added more tests.
There was one thing missing (which is in the second commit): if a non-exported item was used in a public API but not reexported, it was still missing.
cc `@CraftSpider` `@Urgau` `@Enselic`
r? `@notriddle`
|
|
Provide structured suggestion for dropped temp value
|
|
migrate some of `rustc_passes::check_attr`'s diagnostics and derive improvements
- Implements `IntoDiagnosticArg` for `char` using its `Debug` implementation and introduces a macro for those types which just delegate the implementation to `ToString`.
- Apply the `#[rustc_lint_diagnostics]` attribute to `LintDiagnosticBuilder::build` so that diagnostic migration lints will trigger for it - some diagnostics in `rustc_privacy` need updated after this since the lints apply to that crate.
- Add support for `MultiSpan` with any of the attributes that work on a `Span` in the diagnostic derive (`SessionDiagnostic` + `LintDiagnostic`). Requires that diagnostic logic generated for these attributes are emitted in the by-move block rather than the by-ref block that they would normally have been generated in.
- Both diagnostic and subdiagnostic derives were missing the ability to add warnings to diagnostics - this is made more difficult by the `warn` attribute already existing, so this name being unavailable for the derives to use. `#[warn_]` is used instead, which requires special-casing so that `{span_,}warn` is called instead of `{span_,}warn_`.
- Migrate half of the `rustc_passes::check_attr` diagnostics to using diagnostic derives and being translatable. I got tired after a while. I modified some diagnostic output for consistency while doing this, nothing too crazy.
r? `@compiler-errors`
|
|
Allow destructuring opaque types in their defining scopes
fixes #96572
Before this PR, the following code snippet failed with an incomprehensible error, and similar code just ICEd in mir borrowck.
```rust
type T = impl Copy;
let foo: T = (1u32, 2u32);
let (a, b) = foo;
```
The problem was that the last line created MIR projections of the form `foo.0` and `foo.1`, but `foo`'s type is `T`, which doesn't have fields (only its hidden type does). But the pattern supplies enough type information (a tuple of two different inference types) to bind a hidden type.
|
|
Rollup of 7 pull requests
Successful merges:
- #98387 (Add new unstable API `downcast` to `std::io::Error`)
- #98662 (Add std::fs::write documentation precision)
- #99253 (Remove FIXME from MIR `always_storage_live_locals`)
- #99264 (Fix typo in mod.rs)
- #99270 (Add `#[must_use]` to `Box::from_raw`)
- #99277 (Stabilize `core::ffi::CStr`, `alloc::ffi::CString`, and friends)
- #99307 (Add regression test for #64401)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix ICE in `named_arguments_used_positionally` lint
Fixes #99261
Fixes #99289
Fixes #99284
Fixes #99273
Fixes #99297
Fixes #99271
This match pattern:
```
FormatSpec { width: Count::CountIsName(s, _), .. }
| FormatSpec { precision: Count::CountIsName(s, _), .. }
```
does not account for when both `width` and `precision` are both `Count::CountIsName`, so split the check for these two fields into two separate `if let`.
Also, remove any future potential for ICEs by removing the index operator altogether.
---
It is still suspicious that this indexing was broken and caused the ICE, as opposed to just causing a spurious lint message.
cc `@PrestonFrom,` who may be familiar with this code because of implementing the lint this touches, perhaps you'd like to look into why named arguments in `FormatSpec.precision` seem to have indices that don't correspond to a span in `Context.arg_spans`?
Edit: Opened #99265 to track a (related?) incorrect argument indexing issue.
|
|
|
|
|
|
Add Output = expected type trait obligation for known binary operators
This PR is a follow-on to #94034 that addresses #96442. That is, after replacing the trait-suggestion logic in `op.rs` with a more generic path that analyzes a general set of `Obligation`s, then we lost some specificity in the suggestions where the bounds on the associated type `Output=` would not get suggested.
This PR fixes this issue by changing `FnCtxt::construct_obligation_for_trait` to include a new `ProjectionPredicate` obligation for binary operators that obliges that `Output` is the same as the expected type of the expression. Additionally, to get the expected type of the expression, this PR threads the `Expectation<'tcx>` structure throughout several functions.
See src/test/ui/generic-associated-types/missing-bounds.stderr for an example of how this works.
One side effect of this change is it causes type-check failures with binops to include additional information. Specifically, many now say
```
error: type mismatch resolving `<Lhs as TheBinop>::Output == ExpectedTy`
```
It's up for discussion whether this added context is worth it to the user.
r? `@estebank`
|
|
Add regression test for #64401
Closes #64401
r? `@compiler-errors`
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
Add `#[must_use]` to `Box::from_raw`
Fixes #99269
|
|
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
|
|
|
|
trait obligations for binops.
|
|
Revert "Work around invalid DWARF bugs for fat LTO"
Since September, the toolchain has not been generating reliable DWARF
information for static variables when LTO is on. This has affected
projects in the embedded space where the use of LTO is typical. In our
case, it has kept us from bumping past the 2021-09-22 nightly toolchain
lest our debugger break. This has been a pretty dramatic regression for
people using debuggers and static variables. See #90357 for more info
and a repro case.
This commit is a mechanical revert of
d5de680e20def848751cb3c11e1182408112b1d3 from PR #89041, which caused
the issue. (Note on that PR that the commit's author has requested it be
reverted.)
I have locally verified that this fixes #90357 by restoring the
functionality of both the repro case I posted on that bug, and debugger
behavior on real programs. There do not appear to be test cases for this
in the toolchain; if I've missed them, point me at 'em and I'll update
them.
|
|
These test can fail on stage 1
|
|
PR #5956 started checking the stability of path segments.
However, this was not applied to 'use tree' items
(e.g. 'use some::path::{ItemOne, ItemTwo}') due to the way
that we desugar these items in HIR lowering.
This PR modifies 'use tree' lowering to preserve resolution
information, which is needed by stability checking.
|
|
Mark stabilized intrinsics with `rustc_allowed_through_unstable_modules`
Fixes #99286
PR #95956 accidentally made these intrinsics unstable when
accessed through the unstable path segment 'std::intrinsics'
|
|
|
|
|
|
We check that there's a single level of block nesting to ensure always
correct suggestions. If we don't, then we only provide a free-form
message to avoid misleading users in cases like
`src/test/ui/nll/borrowed-temporary-error.rs`.
We could expand the analysis to suggest hoising all of the relevant
parts of the users' code to make the code compile, but that could be
too much.
|
|
|
|
|
|
This reverts commit 08135254dcf22be0d5661ea8f75e703b29a83514.
|
|
stop using `FnCtxt` outside of hir typeck
the requirements between **hir typeck**™, and **not hir typeck**™ are different enough to warrant a full split. with this PR `FnCtxt` is now only used for hir typeck (and for one clippy lint which seems to be emulating hir typeck).
Once this PR has landed I intend to move `FnCtxt` into a new crate. This should also allow some further general improvements here.
r? rust-lang/types
|
|
Fixes #99286
PR #95956 accidentally made these intrinsics unstable when
accessed through the unstable path segment 'std::intrinsics'
|
|
|
