Commit Graph

29225 Commits

Author SHA1 Message Date
Nadrieril
beecd93316 Abstract over per-column pattern traversal 2023-10-27 05:16:13 +02:00
bors
aa91057796 Auto merge of #113183 - estebank:redundant-sized-errors, r=davidtwco
Only emit one error per unsized binding, instead of one per usage

Fix #56607.
2023-10-27 00:06:12 +00:00
Matthias Krüger
2656c987d6
Rollup merge of #117188 - dtolnay:symbolenv, r=cjgillot
Avoid repeated interning of `env!("CFG_RELEASE")`

Implements `@cjgillot's` suggestion from https://github.com/rust-lang/rust/pull/117148#discussion_r1372117485.
2023-10-26 22:26:12 +02:00
Matthias Krüger
a8f7acd8f8
Rollup merge of #117114 - nnethercote:improve-stringify-test, r=petrochenkov
Improve `stringify.rs` test

Best reviewed one commit at a time.

r? `@petrochenkov`
2023-10-26 22:26:11 +02:00
Matthias Krüger
d09c988791
Rollup merge of #117106 - estebank:issue-27300, r=petrochenkov
When expecting closure argument but finding block provide suggestion

Detect if there is a potential typo where the `{` meant to open the closure body was written before the body.

```
error[E0277]: expected a `FnOnce<({integer},)>` closure, found `Option<usize>`
  --> $DIR/ruby_style_closure_successful_parse.rs:3:31
   |
LL |       let p = Some(45).and_then({|x|
   |  ______________________--------_^
   | |                      |
   | |                      required by a bound introduced by this call
LL | |         1 + 1;
LL | |         Some(x * 2)
   | |         ----------- this tail expression is of type `Option<usize>`
LL | |     });
   | |_____^ expected an `FnOnce<({integer},)>` closure, found `Option<usize>`
   |
   = help: the trait `FnOnce<({integer},)>` is not implemented for `Option<usize>`
note: required by a bound in `Option::<T>::and_then`
  --> $SRC_DIR/core/src/option.rs:LL:COL
help: you might have meant to open the closure body instead of placing a closure within a block
   |
LL -     let p = Some(45).and_then({|x|
LL +     let p = Some(45).and_then(|x| {
   |
```

Detect the potential typo where the closure header is missing.

```
error[E0277]: expected a `FnOnce<(&bool,)>` closure, found `bool`
  --> $DIR/block_instead_of_closure_in_arg.rs:3:23
   |
LL |        Some(true).filter({
   |  _________________------_^
   | |                 |
   | |                 required by a bound introduced by this call
LL | |/         if number % 2 == 0 {
LL | ||             number == 0
LL | ||         } else {
LL | ||             number != 0
LL | ||         }
   | ||_________- this tail expression is of type `bool`
LL | |      });
   | |______^ expected an `FnOnce<(&bool,)>` closure, found `bool`
   |
   = help: the trait `for<'a> FnOnce<(&'a bool,)>` is not implemented for `bool`
note: required by a bound in `Option::<T>::filter`
  --> $SRC_DIR/core/src/option.rs:LL:COL
help: you might have meant to create the closure instead of a block
   |
LL |     Some(true).filter(|_| {
   |                       +++
```

Partially address #27300. Fix #104690.
2023-10-26 22:26:11 +02:00
Matthias Krüger
934cbe4637
Rollup merge of #116968 - eopb:116967, r=petrochenkov
Invalid `?` suggestion on mismatched `Ok(T)`

fixes: #116967
2023-10-26 22:26:10 +02:00
bors
8396efecf7 Auto merge of #117228 - matthiaskrgr:rollup-23zzepv, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #116905 (refactor(compiler/resolve): simplify some code)
 - #117095 (Add way to differentiate argument locals from other locals in Stable MIR)
 - #117143 (Avoid unbounded O(n^2) when parsing nested type args)
 - #117194 (Minor improvements to `rustc_incremental`)
 - #117202 (Revert "Remove TaKO8Ki from reviewers")
 - #117207 (The value of `-Cinstrument-coverage=` doesn't need to be `Option`)
 - #117214 (Quietly fail if an error has already occurred)
 - #117221 (Rename type flag `HAS_TY_GENERATOR` to `HAS_TY_COROUTINE`)

r? `@ghost`
`@rustbot` modify labels: rollup
2023-10-26 17:35:23 +00:00
Matthias Krüger
a461de7309
Rollup merge of #117221 - fmease:TypeFlags-HAS_TY_GENERATOR-to-COROUTINE, r=lqd
Rename type flag `HAS_TY_GENERATOR` to `HAS_TY_COROUTINE`

r? oli-obk
2023-10-26 17:45:46 +02:00
Matthias Krüger
70a4678a77
Rollup merge of #117214 - oli-obk:error_shenanigans, r=compiler-errors
Quietly fail if an error has already occurred

fixes #117195
2023-10-26 17:45:46 +02:00
Matthias Krüger
24bdc372fe
Rollup merge of #117207 - Zalathar:no-option, r=compiler-errors
The value of `-Cinstrument-coverage=` doesn't need to be `Option`

(Extracted from #117199, since this is a purely internal cleanup that can land independently.)

Not using this flag is identical to passing `-Cinstrument-coverage=off`, so there's no need to distinguish between `None` and `Some(Off)`.
2023-10-26 17:45:45 +02:00
Matthias Krüger
577026c65c
Rollup merge of #117194 - nnethercote:rustc_incremental, r=cjgillot
Minor improvements to `rustc_incremental`

Just some things I spotted while looking at this code.

r? `@cjgillot`
2023-10-26 17:45:44 +02:00
Matthias Krüger
7eb05480e9
Rollup merge of #117143 - estebank:issue-117080, r=wesleywiser
Avoid unbounded O(n^2) when parsing nested type args

When encountering code like `f::<f::<f::<f::<f::<f::<f::<f::<...` with unmatched closing angle brackets, add a linear check that avoids the exponential behavior of the parse recovery mechanism.

Fix https://github.com/rust-lang/rust/issues/117080, fix https://github.com/rust-lang/rust/issues/115414.
2023-10-26 17:45:44 +02:00
Matthias Krüger
b66c6e719f
Rollup merge of #117095 - klinvill:smir-fn-arg-count, r=oli-obk
Add way to differentiate argument locals from other locals in Stable MIR

This PR resolves rust-lang/project-stable-mir#47 which request a way to differentiate argument locals in a SMIR `Body` from other locals.

Specifically, this PR exposes the `arg_count` field from the MIR `Body`. However, I'm opening this as a draft PR because I think there are a few outstanding questions on how this information should be exposed and described. Namely:

- Is exposing `arg_count` the best way to surface this information to SMIR users? Would it be better to leave `arg_count` as a private field and add public methods (e.g. `fn arguments(&self) -> Iter<'_, LocalDecls>`) that may use the underlying `arg_count` info from the MIR body, but expose this information to users in a more convenient form? Or is it best to stick close to the current MIR convention?
- If the answer to the above point is to stick with the current MIR convention (`arg_count`), is it reasonable to also commit to sticking to the current MIR convention that the first local is always the return local, while the next `arg_count` locals are always the (in-order) argument locals?
- Should `Body` in SMIR only represent function bodies (as implied by the comment I added)? That seems to be the current case in MIR, but should this restriction always be the case for SMIR?

r? `@celinval`
r? `@oli-obk`
2023-10-26 17:45:43 +02:00
Matthias Krüger
17fb2f4b31
Rollup merge of #116905 - Fenex:refactor/compiler/resolve, r=petrochenkov
refactor(compiler/resolve): simplify some code

Removes unnecessary allocate and double-sorting the same vector, makes the code a little nicer.
2023-10-26 17:45:43 +02:00
bors
698db856de Auto merge of #117171 - fee1-dead-contrib:deny-explicit-effect-params, r=oli-obk
Deny providing explicit effect params

r? `@oli-obk`

cc https://github.com/rust-lang/rust/issues/110395
2023-10-26 14:50:23 +00:00
León Orell Valerian Liehr
b1b1458233
Replace type flag HAS_TY_GENERATOR with HAS_TY_COROUTINE 2023-10-26 15:18:50 +02:00
bors
6f65201659 Auto merge of #113262 - Nilstrieb:rawr-casting, r=lcnr
Never consider raw pointer casts to be trival

HIR typeck tries to figure out which casts are trivial by doing them as
coercions and seeing whether this works. Since HIR typeck is oblivious
of lifetimes, this doesn't work for pointer casts that only change the
lifetime of the pointee, which are, as borrowck will tell you, not
trivial.

This change makes it so that raw pointer casts are never considered
trivial.

This also incidentally fixes the "trivial cast" lint false positive on
the same code. Unfortunately, "trivial cast" lints are now never emitted
on raw pointer casts, even if they truly are trivial. This could be
fixed by also doing the lint in borrowck for raw pointers specifically.

fixes #113257
2023-10-26 12:54:19 +00:00
Oli Scherer
d572729d59 Quietly fail if an error has already occurred 2023-10-26 11:14:53 +00:00
bors
9ab0749ce3 Auto merge of #112875 - compiler-errors:negative-coherence-rework, r=lcnr
Rework negative coherence to properly consider impls that only partly overlap

This PR implements a modified negative coherence that handles impls that only have partial overlap.

It does this by:
1. taking both impl trait refs, instantiating them with infer vars
2. equating both trait refs
3. taking the equated trait ref (which represents the two impls' intersection), and resolving any vars
4. plugging all remaining infer vars with placeholder types

these placeholder-plugged trait refs can then be used normally with the new trait solver, since we no longer have to worry about the issue with infer vars in param-envs.

We use the **new trait solver** to reason correctly about unnormalized trait refs (due to deferred projection equality), since this avoid having to normalize anything under param-envs with infer vars in them.

This PR then additionally:
* removes the `FnPtr` knowable hack by implementing proper negative `FnPtr` trait bounds for rigid types.

---

An example:

Consider these two partially overlapping impls:

```
impl<T, U> PartialEq<&U> for &T where T: PartialEq<U> {}
impl<F> PartialEq<F> for F where F: FnPtr {}
```

Under the old algorithm, we would take one of these impls and replace it with infer vars, then try unifying it with the other impl under identity substitutions. This is not possible in either direction, since it either sets `T = U`, or tries to equate `F = &?0`.

Under the new algorithm, we try to unify `?0: PartialEq<?0>` with `&?1: PartialEq<&?2>`. This gives us `?0 = &?1 = &?2` and thus `?1 = ?2`. The intersection of these two trait refs therefore looks like: `&?1: PartialEq<&?1>`. After plugging this with placeholders, we get a trait ref that looks like `&!0: PartialEq<&!0>`, with the first impl having substs `?T = ?U = !0` and the second having substs `?F = &!0`[^1].

Then we can take the param-env from the first impl, and try to prove the negated where clause of the second.

We know that `&!0: !FnPtr` never holds, since it's a rigid type that is also not a fn ptr, we successfully detect that these impls may never overlap.

[^1]: For the purposes of this example, I just ignored lifetimes, since it doesn't really matter.
2023-10-26 10:57:21 +00:00
Oli Scherer
d55487d7e9
Use two slice expressions to save on an offset repetition 2023-10-26 12:32:47 +02:00
David Tolnay
c1552dfddd
Fix symbols::tests::test_symbols
---- symbols::tests::test_symbols stdout ----
    thread 'symbols::tests::test_symbols' panicked at library/proc_macro/src/bridge/client.rs:311:17:
    procedural macro API is used outside of a procedural macro
2023-10-26 02:02:22 -07:00
David Tolnay
ac4fa3f245
Pre-intern a symbol for env!("CFG_RELEASE") 2023-10-26 02:02:22 -07:00
David Tolnay
5563a9ba3d
Improve span of env-related errors 2023-10-26 01:57:12 -07:00
David Tolnay
1078250f48
Continue generating other symbols if an expr is not supported 2023-10-26 01:57:12 -07:00
David Tolnay
65f0253334
Support environment variable for interned Symbol value 2023-10-26 01:57:11 -07:00
David Tolnay
726a43c1de
Move symbols macro map into a struct 2023-10-26 01:57:10 -07:00
David Tolnay
8dea49ad7b
Delete counter from symbols proc macro in favor of hashmap as source of truth 2023-10-26 01:57:09 -07:00
David Tolnay
95742ff23c
Add a Parse impl for symbol Value 2023-10-26 01:57:08 -07:00
David Tolnay
ba17934bc1
Represent symbol value as enum to prepare for supporting env vars 2023-10-26 01:57:07 -07:00
David Tolnay
173dcb211a
Touch up syn parsing in symbols macro 2023-10-26 01:57:06 -07:00
Deadbeef
47efc90366 Deny providing explicit effect params 2023-10-26 08:24:25 +00:00
bors
104ac7bb6a Auto merge of #117148 - dtolnay:sinceversion, r=cjgillot
Store #[stable] attribute's `since` value in structured form

Followup to https://github.com/rust-lang/rust/pull/116773#pullrequestreview-1680913901.

Prior to this PR, if you wrote an improper `since` version in a `stable` attribute, such as `#[stable(feature = "foo", since = "wat.0")]`, rustc would emit a diagnostic saying **_'since' must be a Rust version number, such as "1.31.0"_** and then throw out the whole `stable` attribute as if it weren't there. This strategy had 2 problems, both fixed in this PR:

1. If there was also a `#[deprecated]` attribute on the same item, rustc would want to enforce that the stabilization version is older than the deprecation version. This involved reparsing the `stable` attribute's `since` version, with a diagnostic **_invalid stability version found_** if it failed to parse. Of course this diagnostic was unreachable because an invalid `since` version would have already caused the `stable` attribute to be thrown out. This PR deletes that unreachable diagnostic.

2. By throwing out the `stable` attribute when `since` is invalid, you'd end up with a second diagnostic saying **_function has missing stability attribute_** even though your function is not missing a stability attribute. This PR preserves the `stable` attribute even when `since` cannot be parsed, avoiding the misleading second diagnostic.

Followups I plan to try next:

- Do the same for the `since` value of `#[deprecated]`.

- See whether it makes sense to also preserve `stable` and/or `unstable` attributes when they contain an invalid `feature`. What redundant/misleading diagnostics can this eliminate? What problems arise from not having a usable feature name for some API, in the situation that we're already failing compilation, so not concerned about anything that happens in downstream code?
2023-10-26 06:59:19 +00:00
bors
ccb160d343 Auto merge of #117115 - zetafunction:linking, r=bjorn3
Mark .rmeta files as /SAFESEH on x86 Windows.

Chrome links .rlibs with /WHOLEARCHIVE or -Wl,--whole-archive to prevent the linker from discarding static initializers. This works well, except on Windows x86, where lld complains:

  error: /safeseh: lib.rmeta is not compatible with SEH

The fix is simply to mark the .rmeta as SAFESEH aware. This is trivially true, since the metadata file does not contain any executable code.
2023-10-26 04:04:50 +00:00
Zalathar
9f5fc0283c The value of -Cinstrument-coverage= doesn't need to be Option
Not using this flag is identical to passing `-Cinstrument-coverage=off`, so
there's no need to distinguish between `None` and `Some(Off)`.
2023-10-26 13:33:14 +11:00
bors
6d674af861 Auto merge of #116818 - Nilstrieb:stop-submitting-bug-reports, r=wesleywiser
Stop telling people to submit bugs for internal feature ICEs

This keeps track of usage of internal features, and changes the message to instead tell them that using internal features is not supported.

I thought about several ways to do this but now used the explicit threading of an `Arc<AtomicBool>` through `Session`. This is not exactly incremental-safe, but this is fine, as this is set during macro expansion, which is pre-incremental, and also only affects the output of ICEs, at which point incremental correctness doesn't matter much anyways.

See [MCP 620.](https://github.com/rust-lang/compiler-team/issues/596)

![image](https://github.com/rust-lang/rust/assets/48135649/be661f05-b78a-40a9-b01d-81ad2dbdb690)
2023-10-26 02:08:07 +00:00
Kirby Linvill
4b23bd4734
Update Place and Operand to take slices
The latest locals() method in stable MIR returns slices instead of vecs.
This commit also includes fixes to the existing tests that previously
referenced the private locals field.
2023-10-26 00:21:28 +01:00
Kirby Linvill
fe4dfb814b
Rename internal_locals to inner_locals
The word internal has connotations about information that's not exposed.
It's more accurate to say that the remaining locals apply only to the
inner part of the function, so I'm renaming them to inner locals.
2023-10-26 00:18:42 +01:00
Nicholas Nethercote
e0c990e32c Reduce some function exposure. 2023-10-26 09:04:26 +11:00
Nicholas Nethercote
3cf2a7441f Tiny comment fixes. 2023-10-26 09:04:17 +11:00
Nicholas Nethercote
8da1b33153 Move a use to a more sensible spot.
I.e. in the source file where it's used.
2023-10-26 08:46:10 +11:00
Nicholas Nethercote
ca29c272e7 Reduce exposure of three functions used only within rustc_incremental. 2023-10-26 08:46:10 +11:00
Nicholas Nethercote
72e8690c04 Remove unused never_type feature. 2023-10-26 08:46:10 +11:00
Matthias Krüger
4e4e5619af
Rollup merge of #117175 - oli-obk:gen_fn_split, r=compiler-errors
Rename AsyncCoroutineKind to CoroutineSource

pulled out of https://github.com/rust-lang/rust/pull/116447

Also refactors the printing infra of `CoroutineSource` to be ready for easily extending it with a `Gen` variant for `gen` blocks
2023-10-25 23:37:11 +02:00
Matthias Krüger
2a027faf68
Rollup merge of #117009 - fmease:diag-disambig-sugg-crate, r=b-naber
On unresolved imports, suggest a disambiguated path if necessary to avoid collision with local items

Fixes #116970.
2023-10-25 23:37:10 +02:00
Matthias Krüger
f783ce95ec
Rollup merge of #117008 - compiler-errors:canonical, r=lcnr
Uplift `Canonical` to `rustc_type_ir`

I plan on moving the new trait solver's canonicalizer into either `rustc_type_ir` or a child crate. One dependency on this is lifting `Canonical<V>` to `rustc_type_ir` so we can actually name the canonicalized values.

I may also later lift `CanonicalVarInfo` into the new trait solver. I can't really tell what other changes need to be done, but I'm just putting this up sooner than later since I'm almost certain it'll need to be done regardless of other design choices.

There are a couple of warts introduced by this PR, since we no longer can define inherent `Canonical` impls in `rustc_middle` -- see the changes to:
* `compiler/rustc_trait_selection/src/traits/query/normalize.rs`
* `compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs`

r? lcnr
2023-10-25 23:37:10 +02:00
Matthias Krüger
d30fe8b4e2
Rollup merge of #116931 - weiznich:improve_diagnostic_on_unimplemented_warnings, r=compiler-errors
Improve the warning messages for the `#[diagnostic::on_unimplemented]`

This commit improves warnings emitted for malformed on unimplemented attributes by:

* Improving the span of the warnings
* Adding a label message to them
* Separating the messages for missing and unexpected options
* Adding a help message that says which options are supported

r? `@compiler-errors`

I'm happy to work on further improvements, so feel free to make suggestions.
2023-10-25 23:37:09 +02:00
Matthias Krüger
824dbb53fb
Rollup merge of #116553 - gurry:116464-assoc-type-invalid-suggestion, r=compiler-errors
Do not suggest 'Trait<Assoc=arg>' when in trait impl

Fixes #116464

We now skip the suggestion if we're in an impl of the trait.
2023-10-25 23:37:09 +02:00
Matthias Krüger
d3fb29a422
Rollup merge of #116401 - WaffleLapkin:vtablin''', r=oli-obk
Return multiple object-safety violation errors and code improvements to the object-safety check

See individual commits for more information. Split off of #114260, since it turned out that the main intent of that PR was wrong.

r? oli-obk
2023-10-25 23:37:09 +02:00
Nilstrieb
9d42b1e268 Stop telling people to submit bugs for internal feature ICEs
This keeps track of usage of internal features, and changes the message
to instead tell them that using internal features is not supported.

See MCP 620.
2023-10-25 23:23:04 +02:00
Kirby Linvill
39b293fb5a
Add a public API to get all body locals
This is particularly helpful for the ui tests, but also could be helpful
for Stable MIR users who just want all the locals without needing to
concatenate responses
2023-10-25 22:18:58 +01:00