Commit Graph

24988 Commits

Author SHA1 Message Date
Maybe Waffle
e33e20824f Rename tcx.mk_re_* => Region::new_* 2023-05-29 17:54:53 +00:00
bors
498553fc04 Auto merge of #111235 - loongarch-rs:stabilize-asm, r=Amanieu
Stabilize inline asm for LoongArch64

This PR is used to tracking for stabilize `inline asm` for LoongArch64.

**Status**

- [x] https://github.com/rust-lang/rust/pull/111237
- [x] https://github.com/rust-lang/rust/pull/111332
- [ ] https://github.com/rust-lang/reference/pull/1357

Any others I missed?

r? `@Amanieu`
2023-05-29 13:31:53 +00:00
bors
99ff5afeb8 Auto merge of #111329 - jyn514:metadata-ice, r=bjorn3
Load only the crate header for `locator::crate_matches`

Previously, we used the following info to determine whether to load the crate:
1. The METADATA_HEADER, which includes a METADATA_VERSION constant
2. The embedded rustc version
3. Various metadata in the `CrateRoot`, including the SVH

This worked ok most of the time. Unfortunately, when building locally the rustc version is always
the same because `omit-git-hash` is on by default. That meant that we depended only on 1 and 3, and
we are not very good about bumping METADATA_VERSION (it's currently at 7) so in practice we were
only depending on 3. `CrateRoot` is a very large struct and changes somewhat regularly, so this led
to a steady stream of crashes from trying to load it.

Change the logic to add an intermediate step between 2 and 3: introduce a new `CrateHeader` struct
that contains only the minimum info needed to decide whether the crate should be loaded or not. That
avoids having to load all of `CrateRoot`, which in practice means we should crash much less often.

Note that this works because the SVH should be different between any two dependencies, even if the
compiler has changed, because we use `-Zbinary-dep-depinfo` in bootstrap. See
https://github.com/rust-lang/rust/pull/111329#issuecomment-1538303474 for more details about how the
original crash happened.
2023-05-29 10:40:32 +00:00
bors
70e04bd88d Auto merge of #111748 - nnethercote:Cow-DiagnosticMessage, r=WaffleLapkin
Use `Cow` in `{D,Subd}iagnosticMessage`.

Each of `{D,Subd}iagnosticMessage::{Str,Eager}` has a comment:
```
// FIXME(davidtwco): can a `Cow<'static, str>` be used here?
```
This commit answers that question in the affirmative. It's not the most compelling change ever, but it might be worth merging.

This requires changing the `impl<'a> From<&'a str>` impls to `impl From<&'static str>`, which involves a bunch of knock-on changes that require/result in call sites being a little more precise about exactly what kind of string they use to create errors, and not just `&str`. This will result in fewer unnecessary allocations, though this will not have any notable perf effects given that these are error paths.

Note that I was lazy within Clippy, using `to_string` in a few places to preserve the existing string imprecision. I could have used `impl Into<{D,Subd}iagnosticMessage>` in various places as is done in the compiler, but that would have required changes to *many* call sites (mostly changing `&format("...")` to `format!("...")`) which didn't seem worthwhile.

r? `@WaffleLapkin`
2023-05-29 07:10:44 +00:00
bors
dc0943d2ee Auto merge of #112055 - matthiaskrgr:rollup-y3exx8c, r=matthiaskrgr
Rollup of 5 pull requests

Successful merges:

 - #112029 (Recover upon mistyped error on typo'd `const` in const param def)
 - #112037 (Add details about `unsafe_op_in_unsafe_fn` to E0133)
 - #112039 (compiler: update solaris/illumos to enable tsan support.)
 - #112042 (Migrate GUI colors test to original CSS color format)
 - #112045 (Followup to #111973)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-05-29 03:04:06 +00:00
Matthias Krüger
1e07e5c1f7
Rollup merge of #112039 - devnexen:solarish_compiler_spec_update, r=jackh726
compiler: update solaris/illumos to enable tsan support.
2023-05-29 04:03:02 +02:00
Matthias Krüger
c5a93ba9fe
Rollup merge of #112037 - Nemo157:e0133-unsafe_op_in_unsafe_fn, r=petrochenkov
Add details about `unsafe_op_in_unsafe_fn` to E0133

This was mentioned in https://github.com/rust-lang/rust/pull/99827#discussion_r933899901
2023-05-29 04:03:02 +02:00
Matthias Krüger
45ca2f732e
Rollup merge of #112029 - jieyouxu:typo-const-in-const-param-def, r=cjgillot
Recover upon mistyped error on typo'd `const` in const param def

And add machine-applicable fix for the typo'd `const` keyword.

### Before

```
error: expected one of `,`, `:`, `=`, or `>`, found `N`
 --> src/lib.rs:1:18
  |
1 | pub fn bar<Const N: u8>() {}
  |                  ^ expected one of `,`, `:`, `=`, or `>`
```

### After This PR

```
error: `const` keyword was mistyped as `Const`
 --> test.rs:1:8
  |
1 | fn bar<Const N: u8>() {}
  |        ^^^^^
  |
help: use the `const` keyword
  |
1 | fn bar<const N: u8>() {}
  |        ~~~~~

```

Fixes #111941.
2023-05-29 04:03:01 +02:00
bors
f8447b9638 Auto merge of #111963 - nnethercote:inline-derived-hash, r=lqd
Inline derived `hash`

Because most of the other derived functions are inlined: `clone`, `default`, `eq`, `partial_cmp`, `cmp`. The exception is `fmt`, but it tends to not be on hot paths as much.

r? `@ghost`
2023-05-29 00:25:54 +00:00
Nicholas Nethercote
781111ef35 Use Cow in {D,Subd}iagnosticMessage.
Each of `{D,Subd}iagnosticMessage::{Str,Eager}` has a comment:
```
// FIXME(davidtwco): can a `Cow<'static, str>` be used here?
```
This commit answers that question in the affirmative. It's not the most
compelling change ever, but it might be worth merging.

This requires changing the `impl<'a> From<&'a str>` impls to `impl
From<&'static str>`, which involves a bunch of knock-on changes that
require/result in call sites being a little more precise about exactly
what kind of string they use to create errors, and not just `&str`. This
will result in fewer unnecessary allocations, though this will not have
any notable perf effects given that these are error paths.

Note that I was lazy within Clippy, using `to_string` in a few places to
preserve the existing string imprecision. I could have used `impl
Into<{D,Subd}iagnosticMessage>` in various places as is done in the
compiler, but that would have required changes to *many* call sites
(mostly changing `&format("...")` to `format!("...")`) which didn't seem
worthwhile.
2023-05-29 09:23:43 +10:00
bors
089677eb32 Auto merge of #111813 - scottmcm:pretty-mir, r=cjgillot
MIR: opt-in normalization of `BasicBlock` and `Local` numbering

This doesn't matter at all for actual codegen, but after spending some time reading pre-codegen MIR, I was wishing I didn't have to jump around so much in reading post-inlining code.

So this add two passes that are off by default for every mir level, but can be enabled (`-Zmir-enable-passes=+ReorderBasicBlocks,+ReorderLocals`) for humans.
2023-05-28 21:53:56 +00:00
bors
1c53407e8c Auto merge of #112006 - kylematsuda:earlybinder-private, r=jackh726
Make `EarlyBinder`'s inner value private

Currently, `EarlyBinder(T)`'s inner value is public, which allows implicitly skipping the binder by indexing into the tuple struct (i.e., `x.0`). `@lcnr` suggested making `EarlyBinder`'s inner value private so users are required to explicitly call `skip_binder` (https://github.com/rust-lang/rust/issues/105779#issuecomment-1549933424) .

This PR makes the inner value private, adds `EarlyBinder::new` for constructing a new instance, and replaces uses of `x.0` with `x.skip_binder()` (or similar). It also adds some documentation to `EarlyBinder::skip_binder` explaining how to skip the binder of `&EarlyBinder<T>` to get `&T` now that the inner value is private (since previously we could just do `&x.0`).

r? `@lcnr`
2023-05-28 18:04:53 +00:00
Kyle Matsuda
c29c212f8d Add documentation on skip_binder on how to get &T from &EarlyBinder<T> 2023-05-28 10:44:53 -06:00
Kyle Matsuda
c40e9cc7ca Make EarlyBinder's inner value private; and fix all of the resulting errors 2023-05-28 10:44:53 -06:00
Kyle Matsuda
03534ac8b7 Replace EarlyBinder(x) with EarlyBinder::new(x) 2023-05-28 10:44:50 -06:00
bors
3fae1b9fc3 Auto merge of #111755 - Zoxc:sharded-switch, r=cjgillot
Use only one shard with a single thread

This changes `Sharded` to only access a single shard using a mask set to `0` when a single thread is used, which leads to cache utilization improvements.

Performance improvement with 1 thread and `cfg(parallel_compiler)`:
<table><tr><td rowspan="2">Benchmark</td><td colspan="1"><b>Before</b></th><td colspan="2"><b>After</b></th></tr><tr><td align="right">Time</td><td align="right">Time</td><td align="right">%</th></tr><tr><td>🟣 <b>clap</b>:check</td><td align="right">1.7402s</td><td align="right">1.7004s</td><td align="right">💚  -2.29%</td></tr><tr><td>🟣 <b>hyper</b>:check</td><td align="right">0.2633s</td><td align="right">0.2550s</td><td align="right">💚  -3.12%</td></tr><tr><td>🟣 <b>regex</b>:check</td><td align="right">0.9716s</td><td align="right">0.9482s</td><td align="right">💚  -2.41%</td></tr><tr><td>🟣 <b>syn</b>:check</td><td align="right">1.5679s</td><td align="right">1.5358s</td><td align="right">💚  -2.05%</td></tr><tr><td>🟣 <b>syntex_syntax</b>:check</td><td align="right">6.0569s</td><td align="right">5.9272s</td><td align="right">💚  -2.14%</td></tr><tr><td>Total</td><td align="right">10.5999s</td><td align="right">10.3666s</td><td align="right">💚  -2.20%</td></tr><tr><td>Summary</td><td align="right">1.0000s</td><td align="right">0.9760s</td><td align="right">💚  -2.40%</td></tr></table>

cc `@SparrowLii`
2023-05-28 15:07:33 +00:00
John Kåre Alsaker
8abafd085a Add some comments 2023-05-28 15:54:52 +02:00
John Kåre Alsaker
5843858c01 Don't access self.mask with a single shard 2023-05-28 15:47:44 +02:00
David Carlier
1cae91e9f6 compiler: update solaris and illumos spec to support TSAN. 2023-05-28 13:46:23 +01:00
bors
39c03fb652 Auto merge of #112026 - saethlin:misaligned-addrof, r=pnkfelix
Don't check for misaligned raw pointer derefs inside Rvalue::AddressOf

From https://github.com/rust-lang/rust/pull/112026#issuecomment-1565686697:

rustc 1.70 (stable next week) added a Mir pass to add pointer alignment checks in debug mode. Adding these checks caused some crates to break, but that was expected, since they contain broken code (https://github.com/rust-lang/rust/issues/111487) for tracking that.

However, the checks added are slightly more aggressive than they should have been. Specifically, they also check the place in an `addr_of!` expression. Whether lack of alignment there is or isn't UB is unclear. This PR modifies the pass to not affect those cases.

I spot checked the crater regressions and the ones I saw were not the case that this PR is modifying. It still seems good to not land anything overaggressive though
2023-05-28 12:33:52 +00:00
John Kåre Alsaker
6620882089 Use only one shard with a single thread 2023-05-28 14:08:59 +02:00
Wim Looman
8f94253254
Add details about unsafe_op_in_unsafe_fn to E0133 2023-05-28 13:11:30 +02:00
bors
f59d577838 Auto merge of #112001 - saethlin:enable-matchbranchsimplification, r=cjgillot
Enable MatchBranchSimplification

This pass is one of the small number of benefits from `-Zmir-opt-level=3` that has motivated rustc_codegen_cranelift to use it:

19ed0aade6/compiler/rustc_codegen_cranelift/build_system/build_sysroot.rs (L244-L246)

Cranelift's motivation for this is _runtime_ performance improvements in debug builds. Lifting this pass all the way to `-Zmir-opt-level=1` seems to come without significant perf overhead, so that's what I'm suggesting here.
2023-05-28 09:59:20 +00:00
许杰友 Jieyou Xu (Joe)
41f5a30690
Recover upon encountering mistyped Const in const param def 2023-05-28 16:55:21 +08:00
bors
2560b80a08 Auto merge of #112000 - wesleywiser:safestack, r=Amanieu
Add support for LLVM SafeStack

Adds support for LLVM [SafeStack] which provides backward edge control
flow protection by separating the stack into two parts: data which is
only accessed in provable safe ways is allocated on the normal stack
(the "safe stack") and all other data is placed in a separate allocation
(the "unsafe stack").

SafeStack support is enabled by passing `-Zsanitizer=safestack`.

[SafeStack]: https://clang.llvm.org/docs/SafeStack.html

cc `@rcvalle` #39699
2023-05-28 04:41:13 +00:00
bors
b9c5fdc888 Auto merge of #111378 - jieyouxu:local-shadows-glob-reexport, r=petrochenkov
Add warn-by-default lint when local binding shadows exported glob re-export item

This PR introduces a warn-by-default rustc lint for when a local binding (a use statement, or a type declaration) produces a name which shadows an exported glob re-export item, causing the name from the exported glob re-export to be hidden (see #111336).

### Unresolved Questions

- [x] ~~Is this approach correct? While it passes the UI tests, I'm not entirely convinced it is correct.~~ Seems to be ok now.
- [x] ~~What should the lint be called / how should it be worded? I don't like calling `use x::*;` or `struct Foo;` a "local binding" but they are `NameBinding`s internally if I'm not mistaken.~~ ~~The lint is called `local_binding_shadows_glob_reexport` for now, unless a better name is suggested.~~ `hidden_glob_reexports`.

Fixes #111336.
2023-05-28 01:18:51 +00:00
Ben Kimock
783b1ce99c Exclude Rvalue::AddressOf for raw pointer deref alignment checks 2023-05-27 14:54:15 -04:00
Matthias Krüger
97fae38bf9
Rollup merge of #111181 - bvanjoi:fix-issue-111148, r=davidtwco
fix(parse): return unpected when current token is EOF

close https://github.com/rust-lang/rust/issues/111148

#111148 panic occurred because [FatalError.raise()](https://github.com/bvanjoi/rust/blob/master/compiler/rustc_parse/src/parser/mod.rs#LL540C3-L540C3) was encountered which caused by `Eof` and `Pound`(the last token) had same span, when parsing `#` in `fn a<<i<Y<w<>#`.

<img width="825" alt="image" src="https://user-images.githubusercontent.com/30187863/236612589-9e2c6a0b-18cd-408c-b636-c12a51cbcf1c.png">

There are a few ways to solve this problem:

- Change the action assign for [self.last_unexpected_token_span](https://github.com/rust-lang/rust/blob/master/compiler/rustc_parse/src/parser/diagnostics.rs#L592), for example, if current token is `Eof`, then return Error directly.
- Avoid triggering the `FatalError` when the current token is `Eof`.

I have chosen the second option because executing `expected_one_of_not_found` when the token is `Eof` but not in `ediable` seems reasonable.
2023-05-27 20:40:28 +02:00
Matthias Krüger
0b300a7bfa
Rollup merge of #109084 - dekrain:fix-panic-arg0-expansion, r=petrochenkov
rustc driver: Remove argument 0 before at-expansion to prevent ICE

Under Unix-based operating systems, when I execute rustc by setting argv0 to ``@/dev/null`,` it will expand command-line arguments from this file, leading to an empty arglist, which then triggers an ICE by trying to remove first argument.

The panic message is this:
```
thread 'main' panicked at 'range start index 1 out of range for slice of length 0', compiler/rustc_driver/src/lib.rs:972:17
```

My fix is to remove the first argument before expanding arguments.

<details>
<summary>Full backtrace</summary>

```sh
% (exec -a `@/dev/null` `rustup which rustc`)
thread 'main' panicked at 'range start index 1 out of range for slice of length 0', compiler/rustc_driver/src/lib.rs:972:17
stack backtrace:
   0:     0x7fcec776659a - std::backtrace_rs::backtrace::libunwind::trace::h595f06c70adcc478
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x7fcec776659a - std::backtrace_rs::backtrace::trace_unsynchronized::h177a0149c76cdde9
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x7fcec776659a - std::sys_common::backtrace::_print_fmt::hc0701fd2c3530c58
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/sys_common/backtrace.rs:65:5
   3:     0x7fcec776659a - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hd4cd115d8750fd6c
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/sys_common/backtrace.rs:44:22
   4:     0x7fcec77c839e - core::fmt::write::h93e2f5923c7eca08
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/core/src/fmt/mod.rs:1213:17
   5:     0x7fcec7756be5 - std::io::Write::write_fmt::h8162dbb45f0b9e62
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/io/mod.rs:1682:15
   6:     0x7fcec7766365 - std::sys_common::backtrace::_print::h1835ef8a8f9066da
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/sys_common/backtrace.rs:47:5
   7:     0x7fcec7766365 - std::sys_common::backtrace::print::hcb5e6388b9235f41
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/sys_common/backtrace.rs:34:9
   8:     0x7fcec776912f - std::panicking::default_hook::{{closure}}::h9c084969ccf9a722
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:267:22
   9:     0x7fcec7768e6b - std::panicking::default_hook::h68fa2ba3c3c6c12f
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:286:9
  10:     0x7fcecaab56e4 - <rustc_driver[f4ad927b3c57833d]::DEFAULT_HOOK::{closure#0}::{closure#0} as core[d16e85342ea223d9]::ops::function::FnOnce<(&core[d16e85342ea223d9]::panic::panic_info::PanicInfo,)>>::call_once::{shim:vtable#0}
  11:     0x7fcec776996a - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::h4e6ced11e07d8b24
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/alloc/src/boxed.rs:2002:9
  12:     0x7fcec776996a - std::panicking::rust_panic_with_hook::h8d5c434518ef298c
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:692:13
  13:     0x7fcec77696e9 - std::panicking::begin_panic_handler::{{closure}}::hf33414f5dabf6faf
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:579:13
  14:     0x7fcec7766a4c - std::sys_common::backtrace::__rust_end_short_backtrace::hc50389427413bb75
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/sys_common/backtrace.rs:137:18
  15:     0x7fcec77693f2 - rust_begin_unwind
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:575:5
  16:     0x7fcec77c4d43 - core::panicking::panic_fmt::h2de7a7938f816de8
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/core/src/panicking.rs:64:14
  17:     0x7fcec77cb492 - core::slice::index::slice_start_index_len_fail_rt::h0c87d85ce11d10f6
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/core/src/slice/index.rs:53:5
  18:     0x7fcec77cb416 - core::slice::index::slice_start_index_len_fail::h504609f2a6b168d1
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/core/src/slice/index.rs:41:9
  19:     0x7fceca0eca1f - rustc_driver[f4ad927b3c57833d]::handle_options
  20:     0x7fceca0e037f - <rustc_driver[f4ad927b3c57833d]::RunCompiler>::run
  21:     0x7fceca0dfd0d - <core[d16e85342ea223d9]::panic::unwind_safe::AssertUnwindSafe<rustc_driver[f4ad927b3c57833d]::main::{closure#0}> as core[d16e85342ea223d9]::ops::function::FnOnce<()>>::call_once
  22:     0x7fceca17ce89 - rustc_driver[f4ad927b3c57833d]::main
  23:     0x564f5f008a87 - rustc_main[f164605d1302e295]::main
  24:     0x564f5f008973 - std[3da461b304582a2c]::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>
  25:     0x564f5f008969 - <std[3da461b304582a2c]::rt::lang_start<()>::{closure#0} as core[d16e85342ea223d9]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
  26:     0x7fcec774795c - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h699977d052768608
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/core/src/ops/function.rs:287:13
  27:     0x7fcec774795c - std::panicking::try::do_call::h4e121e623c70f903
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:483:40
  28:     0x7fcec774795c - std::panicking::try::hf9d919e062bc178a
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:447:19
  29:     0x7fcec774795c - std::panic::catch_unwind::h7a7b12272684cb97
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panic.rs:140:14
  30:     0x7fcec774795c - std::rt::lang_start_internal::{{closure}}::hd96b0eb4844b8762
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/rt.rs:148:48
  31:     0x7fcec774795c - std::panicking::try::do_call::h1af1f88f4f92a22c
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:483:40
  32:     0x7fcec774795c - std::panicking::try::hf20d7abea7f0f097
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panicking.rs:447:19
  33:     0x7fcec774795c - std::panic::catch_unwind::hb0e084c3a9c042e4
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/panic.rs:140:14
  34:     0x7fcec774795c - std::rt::lang_start_internal::hca9d5c7277f5b67c
                               at /rustc/2c8cc343237b8f7d5a3c3703e3a87f2eb2c54a74/library/std/src/rt.rs:148:20
  35:     0x564f5f008ab7 - main
  36:     0x7fcec74a1790 - <unknown>
  37:     0x7fcec74a184a - __libc_start_main
  38:     0x564f5f00899e - <unknown>
  39:                0x0 - <unknown>

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.68.0 (2c8cc3432 2023-03-06) running on x86_64-unknown-linux-gnu

query stack during panic:
end of query stack
```
</details>

I also checked if I can trigger a similar problem by passing empty argument list to `execve`, but at least under Linux, it seems to always insert an empty first argument if there are none.
2023-05-27 20:40:27 +02:00
Ben Kimock
7e04c93493 Try enabling MatchBranchSimplification 2023-05-27 13:50:13 -04:00
dekrain
6240d45189 Fix ICE caused by at-expanding argument 0 instead of removing it early 2023-05-27 18:00:43 +02:00
Guillaume Gomez
cd8132bfab
Rollup merge of #111983 - compiler-errors:type-op-locally, r=lcnr
Perform MIR type ops locally in new solver

The new solver already does caching, and it's generally more correct to be using the infcx of the MIR typeck (which has the defining anchor set correctly and has already initialized all the opaques from HIR typeck).

This is based on #111918 so look at the final 3 commits.

This actually causes some tests to go from passing to failing, and failing to passing. Here's the full diff: https://www.diffchecker.com/hB4bh1A9/

Putting this up for exposure mostly.

r? `@lcnr`
2023-05-27 13:38:32 +02:00
Guillaume Gomez
ddb5424569
Rollup merge of #111952 - cjgillot:drop-replace, r=WaffleLapkin
Remove DesugaringKind::Replace.

A simple boolean flag is enough.
2023-05-27 13:38:31 +02:00
许杰友 Jieyou Xu (Joe)
b9606589c4
Add warn-by-default lint for local binding shadowing exported glob re-export item 2023-05-27 18:49:07 +08:00
bors
a525c7ddba Auto merge of #111928 - c410-f3r:dqewdas, r=eholk
[RFC-2011] Expand more expressions

cc #44838

Expands `if`, `let`, `match` and also makes `generic_assert_internals` an allowed feature when using `assert!`. `#![feature(generic_assert)]` is still needed to activate everything.

```rust
#![feature(generic_assert)]

fn fun(a: Option<i32>, b: Option<i32>, c: Option<i32>) {
  assert!(
    if a.is_some() { 1 } else { 2 } == 3
      && if let Some(elem) = b { elem == 4 } else { false }
      && match c { Some(_) => true, None => false }
  );
}

fn main() {
  fun(Some(1), None, Some(2));
}

// Assertion failed: assert!(
//   if a.is_some() { 1 } else { 2 } == 3
//     && if let Some(elem) = b { elem == 4 } else { false }
//     && match c { Some(_) => true, None => false }
// );
//
// With captures:
//   a = Some(1)
//   b = None
//   c = Some(2)
```
2023-05-27 07:02:48 +00:00
Michael Goulet
c4e8a86d9e Don't use outlives type op outside of MIR typeck 2023-05-27 04:13:44 +00:00
Michael Goulet
d7a2fdd4db Uplift complex type ops back into typeck so we can call them locally 2023-05-27 04:13:44 +00:00
Michael Goulet
a25aee1957 Perform MIR type ops locally in new solver 2023-05-27 04:13:44 +00:00
bors
23040c4a5f Auto merge of #111245 - fee1-dead-contrib:temp-fix-tuple-struct-field, r=lcnr
fix for `Self` not respecting tuple Ctor privacy

This PR fixes #111220 by checking the privacy of tuple constructors using `Self`, so the following code now errors
```rust
mod my {
    pub struct Foo(&'static str);
}

impl AsRef<str> for my::Foo {
    fn as_ref(&self) -> &str {
        let Self(s) = self; // previously compiled, now errors correctly
        s
    }
}
```
2023-05-27 01:27:01 +00:00
Matthias Krüger
a99209738e
Rollup merge of #111991 - BoxyUwU:change_error_term_display, r=compiler-errors
Change ty and const error's pretty printing to be in braces

`[const error]` and `[type error]` are slightly confusing since they look like either a slice with an error type for the element ty or a slice with a const argument as the type ???. This PR changes them to display as `{const error}` and `{type error}`  similar to `{integer}`.

This does not update the `Debug` impls for them which is done in #111988.

I updated some error logic to avoid printing the substs of trait refs when unable to resolve an assoc item for them, this avoids emitting errors with `{type error}` in them. The substs are not relevant for these errors since we don't take into account the substs when resolving the assoc item.

r? ``@compiler-errors``
2023-05-27 00:24:01 +02:00
Matthias Krüger
dfdbf1b133
Rollup merge of #111987 - lcnr:alias-relate-coherence, r=BoxyUwU
do not prefer substs relate during coherence

r? ```@compiler-errors```
2023-05-27 00:24:00 +02:00
Matthias Krüger
e7068ff819
Rollup merge of #111954 - asquared31415:unknown_ptr_type_error, r=compiler-errors
improve error message for calling a method on a raw pointer with an unknown pointee

The old error message had very confusing wording.
Also added some more test cases besides the single edition test.

r? `@compiler-errors`
2023-05-27 00:23:58 +02:00
Matthias Krüger
51cf1b62bc
Rollup merge of #111714 - cjgillot:lint-expect-confusion, r=wesleywiser
Stop confusing specification levels when computing expectations.

Fixes https://github.com/rust-lang/rust/issues/111682
2023-05-27 00:23:57 +02:00
Wesley Wiser
019d75b44e Add SafeStack support to rustc
Adds support for LLVM [SafeStack] which provides backward edge control
flow protection by separating the stack into two parts: data which is
only accessed in provable safe ways is allocated on the normal stack
(the "safe stack") and all other data is placed in a separate allocation
(the "unsafe stack").

SafeStack support is enabled by passing `-Zsanitizer=safestack`.

[SafeStack]: https://clang.llvm.org/docs/SafeStack.html
2023-05-26 15:18:54 -04:00
asquared31415
b19466abc2 improve error message for calling a method on a raw pointer with an unknown pointee, and add some tests 2023-05-26 13:15:15 -04:00
Boxy
ad77bc8427 print const and type errors in braces not square brackets 2023-05-26 16:01:29 +01:00
jyn
62314be705 Load only the header for crate_matches
Previously, we used the following info to determine whether to load the crate:
1. The METADATA_HEADER, which includes a METADATA_VERSION constant
2. The embedded rustc version
3. Various metadata in the `CrateRoot`, including the SVH

This worked ok most of the time. Unfortunately, when building locally the rustc version is always
the same because `omit-git-hash` is on by default. That meant that we depended only on 1 and 3, and
we are not very good about bumping METADATA_VERSION (it's currently at 7) so in practice we were
only depending on 3. `CrateRoot` is a very large struct and changes somewhat regularly, so this led
to a steady stream of crashes from trying to load it.

Change the logic to add an intermediate step between 2 and 3: introduce a new `CrateHeader` struct
that contains only the minimum info needed to decide whether the crate should be loaded or not. That
avoids having to load all of `CrateRoot`, which in practice means we should crash much less often.

Note that this works because the SVH should be different between any two dependencies, even if the
compiler has changed, because we use `-Zbinary-dep-depinfo` in bootstrap. See
https://github.com/rust-lang/rust/pull/111329#issuecomment-1538303474 for more details about how the
original crash happened.
2023-05-26 07:44:37 -05:00
lcnr
b6b9611190 remove unnecessary .ok() calls 2023-05-26 11:07:20 +02:00
lcnr
e7fa993d89 do not prefer substs relate during coherence 2023-05-26 11:00:06 +02:00
bors
1221e43bdf Auto merge of #111984 - matthiaskrgr:rollup-6u7ynyv, r=matthiaskrgr
Rollup of 5 pull requests

Successful merges:

 - #111384 (Fix linking Mac Catalyst by including LC_BUILD_VERSION in object files)
 - #111899 (CGU cleanups)
 - #111940 (Clarify safety concern of `io::Read::read` is only relevant in unsafe code)
 - #111947 (Add test for RPIT defined with different hidden types with different substs)
 - #111951 (Correct comment on privately uninhabited pattern.)

Failed merges:

 - #111954 (improve error message for calling a method on a raw pointer with an unknown pointee)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-05-26 08:58:40 +00:00