Commit Graph

29915 Commits

Author SHA1 Message Date
Ralf Jung
d1583eba66 lib features ending in '_internals?' are internal 2023-11-21 08:00:26 +01:00
bors
9a66e4471f Auto merge of #117683 - estebank:priv-builder-sugg, r=cjgillot
When encountering struct fn call literal with private fields, suggest all builders

When encountering code like `Box(42)`, suggest `Box::new(42)` and *all* other associated functions that return `-> Box<T>`.

Add a way to give pre-sorted suggestions.
2023-11-19 20:58:16 +00:00
bors
d19980e1ce Auto merge of #117500 - RalfJung:aggregate-abi, r=davidtwco
Ensure sanity of all computed ABIs

This moves the ABI sanity assertions from the codegen backend to the ABI computation logic. Sadly, due to past mistakes, we [have to](https://github.com/rust-lang/rust/pull/117351#issuecomment-1788495503) be able to compute a sane ABI for nonsensical function types like `extern "C" fn(str) -> str`.  So to make the sanity check pass we first need to make all ABI adjustment deal with unsized types... and we have no shared infrastructure for those adjustments, so that's a bunch of copy-paste. At least we have assertions failing loudly when one accidentally sets a different mode for an unsized argument.

To achieve this, this re-lands the parts of https://github.com/rust-lang/rust/pull/80594 that got reverted in https://github.com/rust-lang/rust/pull/81388.  To avoid breaking wasm ABI again, that ABI now explicitly opts-in to the (wrong, broken) ABI that we currently keep for backwards compatibility. That's still better than having *every* ABI use the wrong broken default!

Cc `@bjorn3`
Fixes https://github.com/rust-lang/rust/issues/115845
2023-11-19 18:42:20 +00:00
Esteban Küber
ac56b06b44 fix rebase 2023-11-19 18:07:22 +00:00
Esteban Küber
b0d7ccb133 fmt 2023-11-19 17:50:47 +00:00
Esteban Küber
a519c9b6b7 review comments 2023-11-19 17:50:47 +00:00
Esteban Küber
4d16171f56 Account for number of arguments in suggestion 2023-11-19 17:50:47 +00:00
Esteban Küber
00265f0cc0 fix tidy 2023-11-19 17:50:47 +00:00
Esteban Küber
69edf8e784 Suggest Default::default() for struct literals with private fields 2023-11-19 17:50:47 +00:00
Esteban Küber
be0958f5ab Suggest builder functions on struct literal with private fields 2023-11-19 17:50:47 +00:00
Esteban Küber
1dfec45dc9 Remove unnecessary .collect() 2023-11-19 17:50:47 +00:00
Esteban Küber
987155f35d Suggest using builder on curly brace struct called as fn 2023-11-19 17:50:46 +00:00
Esteban Küber
12a8bb8d9b Do not suggest struct literal when fields are private 2023-11-19 17:50:46 +00:00
Esteban Küber
a4f47de7ff On private tuple struct, suggest Default::default when possible 2023-11-19 17:50:46 +00:00
Esteban Küber
f1ae02f4bd Don't sort span_suggestions, leave that to caller 2023-11-19 17:50:45 +00:00
Esteban Küber
42aa1273b0 When encountering struct fn call literal with private fields, suggest all builders
When encountering code like `Box(42)`, suggest `Box::new(42)` and *all*
other associated functions that return `-> Box<T>`.
2023-11-19 17:47:41 +00:00
Ralf Jung
c7b8dd4e93 make_direct_deprecated: dont overwrite already set attributes 2023-11-19 16:03:07 +01:00
bors
097261f241 Auto merge of #118054 - max-niederman:pinned-must-use, r=Nilstrieb
Lint pinned `#[must_use]` pointers (in particular, `Box<T>` where `T` is `#[must_use]`) in `unused_must_use`.

Fixes: #111458

This is motivated by a common async/await pattern:

```rs
fn foo() -> Pin<Box<dyn Future<Output = i32>>> {
    Box::pin(async { 42 })
}

// call `foo`, but forget to await the result
foo();
```

Unlike with `async fn` or return position `impl Future`, this does not currently warn the user that the `Future` is unused.

To fix this, I've extended the `unused_must_use` lint to catch `Pin<P>`, where `P` must be used. In particular, this applies to `Pin<Box<T>>`, where `T` must be used. I'm not sure if there are other pointers where this applies, but I can't think of any situation the user wouldn't want to be warned.
2023-11-19 12:23:59 +00:00
bors
d0474fba92 Auto merge of #117807 - RalfJung:raw-str-slice, r=davidtwco
patterns: don't ice when encountering a raw str slice

Fixes https://github.com/rust-lang/rust/issues/117806
2023-11-19 07:44:43 +00:00
bors
7d0e1bca0f Auto merge of #117364 - BlackHoleFox:farewell-bitcode-no-remorse, r=davidtwco
Remove legacy bitcode defaults from all Apple specs

Xcode 14 [deprecated bitcode with warnings](https://developer.apple.com/documentation/xcode-release-notes/xcode-14-release-notes#Deprecations) and now [Xcode 15 has dropped it completely](https://developer.apple.com/documentation/xcode-release-notes/xcode-15-release-notes#Deprecations). `rustc` should follow what the platform tooling is doing as well since it just increases binary sizes for no gain at this point.

`cc` made a [similar change last month](https://github.com/rust-lang/cc-rs/pull/812).

Two things show this should have minimal impact:
- Apple has stopped accepting apps built with versions of Xcode (<14) that generate bitcode
- The app store has been stripping bitcode off IPA releases for over 2 years now.

I didn't nuke all the bitcode changes added in https://github.com/rust-lang/rust/pull/71970/ since maybe another target in the future could need mandatory bitcode embedding.

Staticlibs built for iOS still link correctly with XCode 15 against a test app when using a compiler built from this branch.

cc `@thomcc` `@keith`
2023-11-19 05:35:08 +00:00
Max Niederman
173b950311
catch pinned must_use types in unused_must_use 2023-11-18 20:04:50 -08:00
Takayuki Maeda
9e84f6d86a
Rollup merge of #117110 - estebank:deref-field-suggestion, r=b-naber
Suggest field typo through derefs

Take into account implicit dereferences when suggesting fields.

```
error[E0609]: no field `longname` on type `Arc<S>`
  --> $DIR/suggest-field-through-deref.rs:10:15
   |
LL |     let _ = x.longname;
   |               ^^^^^^^^ help: a field with a similar name exists: `long_name`
```

CC https://github.com/rust-lang/rust/issues/78374#issuecomment-719564114
2023-11-19 04:14:41 +09:00
bors
28345f06d7 Auto merge of #118002 - nnethercote:unify-input-no-input, r=bjorn3
Unify "input" and "no input" paths in `run_compiler`

A follow-up to #117649.

r? `@bjorn3`
2023-11-18 16:43:47 +00:00
bors
33688d2467 Auto merge of #117525 - GKFX:remove_option_payload_ptr, r=petrochenkov
Remove option_payload_ptr; redundant to offset_of

The `option_payload_ptr` intrinsic is no longer required as `offset_of` supports traversing enums (#114208). This PR removes it in order to dogfood offset_of (as suggested at https://github.com/rust-lang/rust/issues/106655#issuecomment-1790907626). However, it will not build until those changes reach beta (which I think is within the next 8 days?) so I've opened it as a draft.
2023-11-18 12:45:42 +00:00
bors
e1e60b6976 Auto merge of #117924 - estebank:issue-53841, r=petrochenkov
When a local binding shadows a fn, point at fn def in call failure

When a local binding shadows a function that is then called, this local binding will cause an E0618 error. We now point not only at the binding definition, but also at the locally defined function of the same name.

```
error[E0618]: expected function, found `&str`
  --> $DIR/issue-22468.rs:3:13
   |
LL |     let foo = "bar";
   |         --- `foo` has type `&str`
LL |     let x = foo("baz");
   |             ^^^-------
   |             |
   |             call expression requires function
...
LL | fn foo(file: &str) -> bool {
   | -------------------------- this function of the same name is available here, but it shadowed by the local binding of the same name
```

Fix #53841
2023-11-18 10:47:33 +00:00
bors
547ace8051 Auto merge of #117742 - weiznich:turn_overlapping_diagnostic_options_into_warnings, r=compiler-errors
Add some additional warnings for duplicated diagnostic items

This commit adds warnings if a user supplies several diagnostic options where we can only apply one of them. We explicitly warn about ignored options here. In addition a small test for these warnings is added.

r? `@compiler-errors`

For now that's the last PR to improve the warnings generated by misused `#[diagnostic::on_unimplemented]` attributes. I'm not sure what needs to be done next to move this closer to stabilization.
2023-11-18 02:57:09 +00:00
Esteban Küber
289ce572b3 tweak logic of "unknown field" label 2023-11-18 00:40:11 +00:00
Esteban Küber
7141399454 When a local binding shadows a fn, point at fn def in call failure
When a local binding shadows a function that is then called, this local
binding will cause an E0618 error. We now point not only at the binding
definition, but also at the locally defined function of the same name.

```
error[E0618]: expected function, found `&str`
  --> $DIR/issue-22468.rs:3:13
   |
LL |     let foo = "bar";
   |         --- `foo` has type `&str`
LL |     let x = foo("baz");
   |             ^^^-------
   |             |
   |             call expression requires function
...
LL | fn foo(file: &str) -> bool {
   | -------------------------- this function of the same name is avalable here, but it shadowed by the local binding of the same name
```

Fix #53841
2023-11-18 00:05:19 +00:00
bors
82b804c744 Auto merge of #118023 - matthiaskrgr:rollup-i9skwic, r=matthiaskrgr
Rollup of 7 pull requests

Successful merges:

 - #117338 (Remove asmjs)
 - #117549 (Use `copied` instead of manual `map`)
 - #117745 (Emit smir)
 - #117964 (When using existing fn as module, don't claim it doesn't exist)
 - #118006 (clarify `fn discriminant` guarantees: only free lifetimes may get erased)
 - #118016 (Add stable mir members to triagebot config)
 - #118022 (Miri subtree update)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-11-17 22:58:19 +00:00
Matthias Krüger
8792e81f29
Rollup merge of #117964 - estebank:issue-81232, r=petrochenkov
When using existing fn as module, don't claim it doesn't exist

Tweak wording of module not found in resolve, when the name exists but belongs to a non-`mod` item.

Fix #81232.
2023-11-17 23:04:23 +01:00
Matthias Krüger
6227455345
Rollup merge of #117745 - ouz-a:emit_smir, r=celinval
Emit smir

This adds ability to `-Zunpretty=smir` and get smir output of a Rust file, this is obliviously pretty basic compared to `mir` output but I think we could iteratively improve it, and even at this state this is useful for us.

r? ``@celinval``
2023-11-17 23:04:23 +01:00
Matthias Krüger
aa2289d3bc
Rollup merge of #117549 - DaniPopes:more-copied, r=b-naber
Use `copied` instead of manual `map`
2023-11-17 23:04:22 +01:00
Matthias Krüger
ca3a02836e
Rollup merge of #117338 - workingjubilee:asmjs-meets-thanatos, r=b-naber
Remove asmjs

Fulfills [MCP 668](https://github.com/rust-lang/compiler-team/issues/668).

`asmjs-unknown-emscripten` does not work as-specified, and lacks essential upstream support for generating asm.js, so it should not exist at all.
2023-11-17 23:04:21 +01:00
bors
2831701757 Auto merge of #114292 - estebank:issue-71039, r=b-naber
More detail when expecting expression but encountering bad macro argument

On nested macro invocations where the same macro fragment changes fragment type from one to the next, point at the chain of invocations and at the macro fragment definition place, explaining that the change has occurred.

Fix #71039.

```
error: expected expression, found pattern `1 + 1`
  --> $DIR/trace_faulty_macros.rs:49:37
   |
LL |     (let $p:pat = $e:expr) => {test!(($p,$e))};
   |                   -------                -- this is interpreted as expression, but it is expected to be pattern
   |                   |
   |                   this macro fragment matcher is expression
...
LL |     (($p:pat, $e:pat)) => {let $p = $e;};
   |               ------                ^^ expected expression
   |               |
   |               this macro fragment matcher is pattern
...
LL |     test!(let x = 1+1);
   |     ------------------
   |     |             |
   |     |             this is expected to be expression
   |     in this macro invocation
   |
   = note: when forwarding a matched fragment to another macro-by-example, matchers in the second macro will see an opaque AST of the fragment type, not the underlying tokens
   = note: this error originates in the macro `test` (in Nightly builds, run with -Z macro-backtrace for more info)
```
2023-11-17 20:57:12 +00:00
Nicholas Nethercote
472f7c97a6 Simplify run_compiler control flow.
I find `Compilation::and_then` hard to read. This commit removes it,
simplifying the control flow in `run_compiler`, and reducing the number
of lines of code.

In particular, `list_metadata` and `process_try_link` (renamed `rlink`)
are now only called if the relevant condition is true, rather than that
condition being checked within the function.
2023-11-18 07:43:51 +11:00
Nicholas Nethercote
5659cc57e9 Factor out two print_crate_info calls. 2023-11-18 07:40:37 +11:00
Nicholas Nethercote
446c8e06d9 Move describe_lints calls.
Currently we have an inconsistency between the "input" and "no input"
cases:
- no input: `rustc --print=sysroot -Whelp` prints the lint help.
- input:    `rustc --print=sysroot -Whelp a.rs` prints the sysroot.

It makes sense to print the lint help in both cases, because that's what
happens with `--help`/`-Zhelp`/`-Chelp`.

In fact, the `describe_lints` in the "input" case happens amazingly
late, after *parsing*. This is because, with plugins, lints used to be
registered much later, when the global context was created. But #117649
moved lint registration much earlier, during session construction.

So this commit moves the `describe_lints` call to a single spot for both
for both the "input" and "no input" cases, as early as possible. This is
still not as early as `--help`/`-Zhelp`/`-Chelp`, because `-Whelp` must
wait until the session is constructed.
2023-11-18 07:39:15 +11:00
Nicholas Nethercote
8aee35e2ed Merge interface::run_compiler calls.
`rustc_driver_impl::run_compiler` currently has two
`interface::run_compiler` calls: one for the "no input" case, and one
for the normal case.

This commit merges the former into the latter, which makes the control
flow easier to read and avoids some duplication.

It also makes it clearer that the "no input" case will describe lints
before printing crate info, while the normal case does it in the reverse
order. Possibly a bug?
2023-11-18 07:38:05 +11:00
ouz-a
92657f163a use new apis and add new function 2023-11-17 23:28:17 +03:00
Nicholas Nethercote
706eb1604b Rename early_error_handler as default_handler.
Yes, its type is `EarlyErrorHandler`, but there is another value of that
type later on in the function called `handler` that is initialized with
`sopts.error_format`. So `default_handler` is a better name because it
clarifies that it is initialized with `ErrorOutputType::default()`.
2023-11-18 07:17:35 +11:00
bors
e886137e18 Auto merge of #117993 - nnethercote:streamline-Linker, r=bjorn3
Streamline `Linker`

r? `@bjorn3`
2023-11-17 16:49:58 +00:00
bors
069a4af48b Auto merge of #117944 - lcnr:region-refactor-uwu, r=BoxyUwU
some additional region refactorings

the commits are selfcontained 

r? `@BoxyUwU`
2023-11-17 14:27:20 +00:00
bors
4d7f952a02 Auto merge of #112422 - aliemjay:implied-bounds-placeholders, r=lcnr
ignore implied bounds with placeholders

given the following code:
```rust
trait Trait {
    type Ty<'a> where Self: 'a;
}

impl<T> Trait for T {
    type Ty<'a> = () where Self: 'a;
}

struct Foo<T: Trait>(T)
where
    for<'x> T::Ty<'x>: Sized;
```

when computing the implied bounds from `Foo<X>` we incorrectly get the bound `X: !x` from the normalization of ` for<'x> <X as Trait>::Ty::<'x>: Sized`. This is a a known bug! we shouldn't use the constraints that arise from normalization as implied bounds. See #109628.

Ignore these bounds for now. This should prevent later ICEs.

Fixes #112250
Fixes #107409
2023-11-17 12:16:53 +00:00
Oğuz Ağcayazı
71c990470a move pretty into stable_mir 2023-11-17 13:28:43 +03:00
Oğuz Ağcayazı
3883645a9b change smir to StableMir 2023-11-17 13:28:07 +03:00
Oğuz Ağcayazı
c821603484 remove unwrap 2023-11-17 13:28:07 +03:00
Oğuz Ağcayazı
ebd9c145f6 better formatting for statements 2023-11-17 13:28:07 +03:00
Oğuz Ağcayazı
0f0e9baf19 cover statements 2023-11-17 13:28:07 +03:00
Oğuz Ağcayazı
ae179a04b6 emit basic smir 2023-11-17 13:28:07 +03:00
bors
78efca8845 Auto merge of #117278 - lcnr:try-normalize-ty, r=compiler-errors
new solver normalization improvements

cool beans

At the core of this PR is a `try_normalize_ty` which stops for rigid aliases by using `commit_if_ok`.

Reworks alias-relate to fully normalize both the lhs and rhs and then equate the resulting rigid (or inference) types. This fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/68 by avoiding the exponential blowup. Also supersedes #116369 by only defining opaque types if the hidden type is rigid.

I removed the stability check in `EvalCtxt::evaluate_goal` due to https://github.com/rust-lang/trait-system-refactor-initiative/issues/75. While I personally have opinions on how to fix it, that still requires further t-types/`@nikomatsakis` buy-in, so I removed that for now. Once we've decided on our approach there, we can revert this commit.

r? `@compiler-errors`
2023-11-17 10:16:41 +00:00