mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
172,792 Commits 2 Branches 0 Tags 1.4 GiB
bfd0435fd7
Commit Graph

172792 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
Tomasz Miąsko
45afc214af Update invalid atomic ordering lint 
The restriction that success ordering must be at least as strong as its
failure ordering in compare-exchange operations was lifted in #98383.
 2022-07-18 12:02:11 +02:00
Philipp Krones
7fab8a4016
Merge commit 'fdb84cbfd25908df5683f8f62388f663d9260e39' into clippyup 2022-07-18 09:39:37 +02:00
Jordan McQueen
38f090b5e9 Use span_bug for unexpected field projection type 
Improves the compiler error backtrace information, as shown in #99363,
by using `span_bug` instead of `bug`.

New output:

```
build/aarch64-apple-darwin/stage1/bin/rustc /tmp/test.rs --edition=2021
error: internal compiler error: compiler/rustc_middle/src/ty/closure.rs:185:25: Unexpected type Opaque(DefId(0:5 ~ test[db0f]::main::T::{opaque#0}), []) for `Field` projection
  --> /tmp/test.rs:11:27
   |
11 |         let Foo((a, b)) = foo;
   |                           ^^^

thread 'rustc' panicked at 'Box<dyn Any>', /Users/jmq/src/forked/rust/compiler/rustc_errors/src/lib.rs:1331:9
stack backtrace:
```

(Remainder of output truncated.)
 2022-07-18 16:24:08 +09:00
David Herberth
c1c1abc08a Use split_once in FromStr docs 2022-07-18 08:57:43 +02:00
bors
880416180b Auto merge of #99181 - lcnr:arenaGTrc, r=wesleywiser 
`arena > Rc` for query results

The `Rc`s have to live for the whole duration as their count cannot go below 1 while stored as part of the query results.

By storing them in an arena we should save a bit of memory because we don't have as many independent allocations and also don't have to clone the `Rc` anymore.
 2022-07-18 05:50:54 +00:00
Takayuki Maeda
a22934bea1 avoid Symbol to &str conversions 2022-07-18 14:25:34 +09:00
bors
2fa64d0e53 Auto merge of #99137 - jackh726:wf-no-infcx, r=estebank 
Don't pass InferCtxt to WfPredicates

Simple cleanup. Infer vars will get passed up as obligations and shallowed resolved later. This actually improves one test output.
 2022-07-18 03:07:26 +00:00
Yuki Okushi
5172a2f5ce
Add regression test for #95230 
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
 2022-07-18 10:15:09 +09:00
Nicholas Nethercote
13bf958b7f Fix debuginfo tests. 
This is needed for my Ubuntu 22.04 box due to a slight change in gdb
output. The fix is similar to the fix in #95063.
 2022-07-18 10:34:41 +10:00
bors
e1d9a202fc Auto merge of #99391 - JohnTitor:rollup-tdigzzo, r=JohnTitor 
Rollup of 6 pull requests

Successful merges:

 - #98383 (Remove restrictions on compare-exchange memory ordering.)
 - #99350 (Be more precise when suggesting removal of parens on unit ctor)
 - #99356 (Do not constraint TAITs when checking impl/trait item compatibility)
 - #99360 (Do not ICE when we have `-Zunpretty=expanded` with invalid ABI)
 - #99373 (Fix source code sidebar tree auto-expand)
 - #99374 (Fix doc for `rchunks_exact`)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
 2022-07-18 00:26:44 +00:00
Yuki Okushi
7c98c92ebc
Rollup merge of #99374 - TethysSvensson:patch-1, r=Dylan-DPC 
Fix doc for `rchunks_exact`

`rchunks_exact` is not a more optimized version of `chunks`, but of `rchunks`.
 2022-07-18 08:40:02 +09:00
Yuki Okushi
7bbb753d08
Rollup merge of #99373 - GuillaumeGomez:source-code-sidebar-tree-auto-expand, r=notriddle 
Fix source code sidebar tree auto-expand

Here is the bug:

![Screenshot from 2022-07-17 13-32-00](https://user-images.githubusercontent.com/3050060/179397712-bfb1c279-0ed2-4cb5-aef5-05741921bcc3.png)

It was happening because as soon as we found the file (from the URL), every item following it was then opened, even if it wasn't supposed to.

The GUI test ensures that it doesn't happen by adding two nested levels and ensuring only this path is "open".

r? ``@notriddle``
 2022-07-18 08:40:01 +09:00
Yuki Okushi
f3a458f735
Rollup merge of #99360 - compiler-errors:issue-99331, r=fee1-dead 
Do not ICE when we have `-Zunpretty=expanded` with invalid ABI

Fixes #99331
 2022-07-18 08:40:00 +09:00
Yuki Okushi
3c2175b8a2
Rollup merge of #99356 - compiler-errors:tait-in-assoc-ty-supertraits, r=oli-obk 
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``
 2022-07-18 08:39:59 +09:00
Yuki Okushi
cc35c787aa
Rollup merge of #99350 - compiler-errors:issue-99240, r=fee1-dead 
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?
 2022-07-18 08:39:58 +09:00
Yuki Okushi
796bc7cae3
Rollup merge of #98383 - m-ou-se:remove-memory-order-restrictions, r=joshtriplett 
Remove restrictions on compare-exchange memory ordering.

We currently don't allow the failure memory ordering of compare-exchange operations to be stronger than the success ordering, as was the case in C++11 when its memory model was copied to Rust. However, this restriction was lifted in C++17 as part of [p0418r2](https://wg21.link/p0418r2). It's time  we lift the restriction too.

| Success | Failure | Before | After |
|---------|---------|--------|-------|
| Relaxed | Relaxed | ✔️ | ✔️ |
| Relaxed | Acquire | ❌                | ✔️ |
| Relaxed | SeqCst  | ❌                | ✔️ |
| Acquire | Relaxed | ✔️ | ✔️ |
| Acquire | Acquire | ✔️ | ✔️ |
| Acquire | SeqCst  | ❌                | ✔️ |
| Release | Relaxed | ✔️ | ✔️ |
| Release | Acquire | ❌                | ✔️ |
| Release | SeqCst  | ❌                | ✔️ |
| AcqRel  | Relaxed | ✔️ | ✔️ |
| AcqRel  | Acquire | ✔️ | ✔️ |
| AcqRel  | SeqCst  | ❌                | ✔️ |
| SeqCst  | Relaxed | ✔️ | ✔️ |
| SeqCst  | Acquire | ✔️ | ✔️ |
| SeqCst  | SeqCst  | ✔️ | ✔️ |
| \*      | Release | ❌                | ❌                |
| \*      | AcqRel  | ❌                | ❌                |

Fixes https://github.com/rust-lang/rust/issues/68464
 2022-07-18 08:39:57 +09:00
Michael Howell
1169832f2f rustdoc: extend #[doc(tuple_variadic)] to fn pointers 
The attribute is also renamed `fake_variadic`.
 2022-07-17 16:32:06 -07:00
bors
fdb84cbfd2 Auto merge of #9196 - alex-semenyuk:invalid_regex, r=Jarcho 
Fix example for `clippy::invalid_regex`

Close #9194
changelog: previous example doesn't trigger lint
 2022-07-17 23:08:04 +00:00
bors
246f66a905 Auto merge of #99062 - Kobzol:lld-icf, r=jyn514 
Use ICF (identical code folding) for building rustc

It seems that ICF (identical code folding) is able to remove duplicated functions created by monomorphization from binaries, resulting in smaller binary size and better i-cache utilization. Let's see if it helps for `rustc`.

I'm not sure if `lld` is even used for linking `rustc` on the Linux `dist` builder, let's see.
 2022-07-17 21:42:52 +00:00
alexey semenyuk
142898e544
Fix example for clippy::invalid_regex 2022-07-18 00:35:34 +03:00
bors
263edd43c5 Auto merge of #99033 - 5225225:interpreter-validity-checks, r=oli-obk 
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 :)
 2022-07-17 19:28:01 +00:00
Michael Goulet
6d2bd541e0 use body's param-env when checking if type needs drop 2022-07-17 10:56:12 -07:00
Jakub Beránek
97f6f95879
Use LLD linker for compiling rustc on Linux x64 and use ICF for binary size optimization 2022-07-17 17:37:10 +02:00
Guillaume Gomez
98bceb0d24 Add GUI test for source code sidebar auto-expand 2022-07-17 17:04:43 +02:00
Ralf Jung
e6be52bbbd interpret/visitor: add missing early return 2022-07-17 10:47:34 -04:00
bors
3a4e4575ed Auto merge of #9022 - alex-semenyuk:needless_option_take_more_docs, r=Jarcho 
`NEEDLESS_OPTION_TAKE` doc improvements

changelog: More info on `NEEDLESS_OPTION_TAKE`
 2022-07-17 13:33:40 +00:00
alexey semenyuk
e7804355de NEEDLESS_OPTION_TAKE doc improvements 
NEEDLESS_OPTION_TAKE doc improvements

NEEDLESS_OPTION_TAKE doc improvements

NEEDLESS_OPTION_TAKE doc improvements

NEEDLESS_OPTION_TAKE doc improvements

NEEDLESS_OPTION_TAKE doc improvements

NEEDLESS_OPTION_TAKE doc improvements

NEEDLESS_OPTION_TAKE doc improvements
 2022-07-17 16:13:58 +03:00
bors
c2ecd3af87 Auto merge of #99283 - RalfJung:miri, r=RalfJung 
update Miri

Fixes https://github.com/rust-lang/rust/issues/99224
r? `@ghost`
 2022-07-17 13:08:06 +00:00
Ralf Jung
9b49a792ef make tidy accept another permutation of this license string 2022-07-17 08:47:42 -04:00
Ralf Jung
10430dbf8e update Miri 2022-07-17 08:47:42 -04:00
Tethys Svensson
8c58de5e2c
Fix for rchunks_exact doc 
`rchunks_exact` is not a more optimized version of `chunks`, but of `rchunks`.
 2022-07-17 14:18:36 +02:00
Guillaume Gomez
3024d399a2 Fix auto-expand of trees in source code page sidebar 2022-07-17 14:11:45 +02:00
bors
967a9c94b3 Auto merge of #99040 - gimbles:ci-std-tests, r=pietroalbini 
Run stage 0 std tests in CI

Fixes https://github.com/rust-lang/rust/issues/95996
 2022-07-17 10:40:56 +00:00
Michael Goulet
7a45a60418 use rustc_hir_pretty::qpath_to_string to avoid span_to_snippet when rendering path 2022-07-17 04:58:38 +00:00
bors
1cd72b7343 Auto merge of #99362 - JohnTitor:rollup-4d5zo9d, r=JohnTitor 
Rollup of 7 pull requests

Successful merges:

 - #94927 (Stabilize `let_chains` in Rust 1.64)
 - #97915 (Implement `fmt::Write` for `OsString`)
 - #99036 (Add `#[test]` to functions in test modules)
 - #99088 (Document and stabilize process_set_process_group)
 - #99302 (add tracking issue to generic member access APIs)
 - #99306 (Stabilize `future_poll_fn`)
 - #99354 (Add regression test for #95829)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
 2022-07-17 04:11:33 +00:00
Yuki Okushi
1d193236b0
Rollup merge of #99354 - JohnTitor:issue-95829, r=compiler-errors 
Add regression test for #95829

Closes #95829
r? `@compiler-errors`

Signed-off-by: Yuki Okushi <jtitor@2k36.org>
 2022-07-17 13:08:53 +09:00
Yuki Okushi
50527690e2
Rollup merge of #99306 - JohnTitor:stabilize-future-poll-fn, r=joshtriplett 
Stabilize `future_poll_fn`

FCP is done: https://github.com/rust-lang/rust/issues/72302#issuecomment-1179620512
Closes #72302

r? `@joshtriplett` as you started FCP

Signed-off-by: Yuki Okushi <jtitor@2k36.org>
 2022-07-17 13:08:52 +09:00
Yuki Okushi
28cce683ad
Rollup merge of #99302 - yaahc:gma-tracking-issue, r=joshtriplett 
add tracking issue to generic member access APIs

Missed as part of https://github.com/rust-lang/rust/pull/98072
 2022-07-17 13:08:51 +09:00
Yuki Okushi
f49d267136
Rollup merge of #99088 - niklasf:stabilize-process_set_process_group, r=joshtriplett 
Document and stabilize process_set_process_group

Tracking issue: https://github.com/rust-lang/rust/issues/93857

FCP finished here: https://github.com/rust-lang/rust/issues/93857#issuecomment-1179551697
 2022-07-17 13:08:50 +09:00
Yuki Okushi
0748638cf9
Rollup merge of #99036 - TaKO8Ki:fix-test-for-88138, r=compiler-errors 
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.
 2022-07-17 13:08:49 +09:00
Yuki Okushi
48cf43b752
Rollup merge of #97915 - tbu-:pr_os_string_fmt_write, r=joshtriplett 
Implement `fmt::Write` for `OsString`

This allows to format into an `OsString` without unnecessary
allocations. E.g.

```
let mut temp_filename = path.into_os_string();
write!(&mut temp_filename, ".tmp.{}", process::id());
```
 2022-07-17 13:08:48 +09:00
Yuki Okushi
353d0180bb
Rollup merge of #94927 - c410-f3r:stabilize-let-chains, r=joshtriplett 
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
 2022-07-17 13:08:47 +09:00
Michael Goulet
26ecd44160 Do not ICE when we have -Zunpretty=expand with invalid ABI 2022-07-16 20:35:54 -07:00
Michael Goulet
23cb89ea38 Do not constraint TAITs when checking impl/trait item compatibility 2022-07-16 18:36:08 -07:00
Michael Howell
c8221830c7 rustdoc: avoid inlining items with duplicate (type, name) 
Fixes #99221
 2022-07-16 17:04:43 -07:00
Yuki Okushi
a94e6c78a2
Add regression test for #95829 
Signed-off-by: Yuki Okushi <jtitor@2k36.org>
 2022-07-17 08:50:41 +09:00
bors
db41351753 Auto merge of #98866 - nagisa:nagisa/align-offset-wroom, r=Mark-Simulacrum 
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.
 2022-07-16 23:28:28 +00:00
Caio
3266460749 Stabilize let_chains 2022-07-16 20:17:58 -03:00
Michael Goulet
75a1b1cf06 Use typeck_results to get accurate qpath res for arg mismatch error 2022-07-16 22:29:52 +00:00
Simonas Kazlauskas
62a182cf7f 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.
 2022-07-17 01:27:37 +03:00