Perform WF-check on `type`s with no type parameters #69741

estebank · 2020-03-05T19:19:18Z

Start performing a WF-check on types without type parameters to verify that they will be able to be constructed.
Do not perform a Sized check, as type T = dyn Trait; should be allowed.
Do not WF-check types with type parameters because we currently lint against type T<X: Trait> = K<X>; because we do not propagate X: Trait, which means that we currently allow type T<X> = <X as Trait>::Foo;, which would be rejected if we WF-checked it because it would need to be written as type T<X: Trait> = <X as Trait>::Foo; to be correct.

Instead, we simply don't check it at definition and only do so at use like we do currently. In the future, the alternatives would be to either automatically backpropagate the X: Trait obligation when WF-checking the type or (my preferred solution) properly propagate the explicit X: Trait obligation to the uses, which would likely be a breaking change.

Fixes #60980 by using a more appropriate span for the error.

rust-highfive · 2020-03-05T19:19:22Z

r? @varkor

(rust_highfive has picked a reviewer for you, use r? to override)

estebank · 2020-03-05T19:19:44Z

CC @eddyb @Centril @nikomatsakis

estebank · 2020-03-05T20:51:18Z

src/test/ui/structs/struct-path-alias-bounds.stderr

 error[E0277]: the trait bound `NoClone: std::clone::Clone` is not satisfied
-  --> $DIR/struct-path-alias-bounds.rs:9:13
+  --> $DIR/struct-path-alias-bounds.rs:6:10
   |
 LL | struct S<T: Clone> { a: T }
   | ------------------ required by `S`
 ...
-LL |     let s = A { a: NoClone };
-   |             ^ the trait `std::clone::Clone` is not implemented for `NoClone`
+LL | type A = S<NoClone>;
+   |          ^^^^^^^^^^ the trait `std::clone::Clone` is not implemented for `NoClone`


This is the category of errors I wanted to improve.

nikomatsakis · 2020-03-09T17:36:35Z

I would indeed like to make progress on this but I'm a bit nervous about making this change in isolation, without a broader plan in place. We should do a crater run to get an idea of the impact, this may require future compatibility warnings.

estebank · 2020-03-09T21:11:24Z

@bors try @craterbot check

bors · 2020-03-09T21:11:38Z

⌛ Trying commit 6d65bc6f491739479c2eb69b7280cf772ece1a4d with merge 89c05fd3cc6404a13e1bd71450c6132a2755fa4b...

bors · 2020-03-10T00:19:41Z

☀️ Try build successful - checks-azure
Build commit: 89c05fd3cc6404a13e1bd71450c6132a2755fa4b (89c05fd3cc6404a13e1bd71450c6132a2755fa4b)

estebank · 2020-03-10T23:50:04Z

@craterbot check

craterbot · 2020-03-10T23:50:07Z

👌 Experiment pr-69741 created and queued.
🤖 Automatically detected try build 89c05fd3cc6404a13e1bd71450c6132a2755fa4b
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2020-03-10T23:50:11Z

🚧 Experiment pr-69741 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

eddyb · 2020-03-12T15:42:19Z

Someone (maybe me later if someone reminds me in PM) should find the late 2018 PRs/issues relevant to this, since it's quite possible we did this exact crater run then.

estebank · 2020-03-12T17:07:53Z

@eddyb I'll dig into it, but in the meantime I thought it was a good idea to test again because even if the semantic consequences of this change haven't changed since then, the ecosystem's reliance on the current behavior might have.

craterbot · 2020-03-13T23:40:32Z

🎉 Experiment pr-69741 is completed!
📊 41 regressed and 1 fixed (95178 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

estebank · 2020-03-14T00:48:19Z

bitvec and domain seem to be the crates most affected by this change.

estebank · 2020-03-23T01:00:52Z

I reached out to the bitvec author and this was a deprecation placeholder that users are not supposed to be using and will be removed in the next version. It was also likely used by accident, which lends credence to my gut feeling that it's imperative to start fixing this sooner rather that later.

varkor · 2020-03-26T20:45:22Z

Are we waiting on the lang team to discuss this again, or is this ready for review?

Centril · 2020-03-26T20:46:53Z

Probably the former :)

lcnr · 2021-03-02T14:57:08Z

This PR seems to make a somewhat surprising distinction between type aliases with and without parameters? If I read the comments above correctly, the former require WF while the latter do not, and the plan is to keep it like that. Isn't that strangely inconsistent, or am I misunderstanding something?

This distinction is already the case for type param defaults, so the following doesn't error even though the type default isn't wf.

struct Foo<T, U = (Vec<[u32]>, T)>(T, U);

Have we tried always erroring on eval errors of constants in type aliases? I don't think there is much, if any, code using incorrect constants there. So i personally would be interested in trying that instead of modifying const eval.

oli-obk · 2021-03-02T15:07:29Z

Have we tried always erroring on eval errors of constants in type aliases?

This is what is done right now, and there were no regressions on crater that had const eval errors (I just checked again).

oli-obk · 2021-03-29T10:24:44Z

src/test/ui/consts/const-eval/pub_const_err.rs

+//pub type Foo = [i32; 0 - 1];
+//^ evaluation of constant value failed


Please turn these into error tests (see https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/erroneous.20constants.20in.20type.20alias/near/229492342 for "lang team sign off on making this a hard error since crater is clean")

nikomatsakis · 2021-04-01T18:32:53Z

To be clear, I thought the @rust-lang/lang consensus was that we would be ok with issuing warnings, but not errors.

oli-obk · 2021-04-01T19:06:40Z

To be clear, I thought the @rust-lang/lang consensus was that we would be ok with issuing warnings, but not errors.

Yes, but constants were not discussed. So I brought it up on zulip, and my message got one textual approval and two thumbs-up reactions.

nikomatsakis · 2021-04-01T19:37:14Z

Perhaps I am missing something.

oli-obk · 2021-04-01T21:06:50Z

I created a workaround that does not hard error in #82700 but it made no one in @rust-lang/wg-const-eval happy (including myself). The main difference between hard erroring on constants and hard erroring on other wf-bounds checks failing is that the latter has crater regressions while the former does not. Other than that, the reasoning about making it hard errors or not is the same.

nikomatsakis · 2021-04-02T14:07:53Z

Hmm. My problem with hard errors on other wf-bounds checks is not that they have crater regressions, but that it's inconsistent to do so only in narrow cases. I'm not sure what would make constants different from anything else: I guess it's just that we get ICEs sometimes with constants? This seems related to the questions we were discussing in our recent meeting.

bors · 2021-04-29T20:32:48Z

☔ The latest upstream changes (presumably #84556) made this pull request unmergeable. Please resolve the merge conflicts.

oli-obk · 2021-05-03T07:59:04Z

I'm not sure what would make constants different from anything else: I guess it's just that we get ICEs sometimes with constants?

No, the problem is that error reporting on constants happens inside the query that evaluates the constant. We would need to walk up the DefId parents of a constant to see whether it is part of a type alias and then change the behaviour of the error reporting. This is possible, but it complicates our ctfe error reporting machinery further.

nikomatsakis · 2021-05-03T19:55:21Z

I see, that's interesting. I think my expectation is that we would simply not evaluate the default value in any way until it is used. I guess this is not what we do?

oli-obk · 2021-05-03T20:21:41Z

Wf-check evaluated all constants, because "an array type whose length computation errors is not well formed". At least that was how I understood wfcheck in other places. We could generally stop const evaluating during wfcheck, even in other situations and leave it to the usages, but I'm not sure what the ramnifications of that are

Dylan-DPC · 2022-05-31T12:11:15Z

@oli-obk @nikomatsakis is there any update on this?

JohnCSimon · 2022-11-27T02:08:10Z

@estebank
Ping from triage: I'm closing this due to inactivity, Please reopen when you are ready to continue with this.
Note: if you do please open the PR BEFORE you push to it, else you won't be able to reopen - this is a quirk of github.
Thanks for your contribution.

@rustbot label: +S-inactive

rust-highfive assigned varkor Mar 5, 2020

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 5, 2020

estebank mentioned this pull request Mar 5, 2020

Misleading diagnostic span using trait projections in arguments #60980

Closed

estebank commented Mar 5, 2020

View reviewed changes

Centril added I-nominated T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Mar 6, 2020

craterbot added S-waiting-on-crater Status: Waiting on a crater run to be completed. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 10, 2020

craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Mar 13, 2020

Centril added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 26, 2020

crlf0710 removed the S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). label Apr 24, 2020

crlf0710 added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Mar 20, 2021

oli-obk reviewed Mar 29, 2021

View reviewed changes

crlf0710 added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Apr 23, 2021

crlf0710 added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels May 22, 2021

crlf0710 added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Jun 11, 2021

crlf0710 added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Jul 4, 2021

crlf0710 added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Jul 24, 2021

crlf0710 added S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). and removed S-waiting-on-team Status: Awaiting decision from the relevant subteam (see the T-<team> label). labels Sep 10, 2021

JohnCSimon closed this Nov 27, 2022

rustbot added the S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. label Nov 27, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Perform WF-check on `type`s with no type parameters #69741

Perform WF-check on `type`s with no type parameters #69741

estebank commented Mar 5, 2020 •

edited

Loading

rust-highfive commented Mar 5, 2020

estebank commented Mar 5, 2020

estebank Mar 5, 2020

nikomatsakis commented Mar 9, 2020

estebank commented Mar 9, 2020

bors commented Mar 9, 2020

bors commented Mar 10, 2020

estebank commented Mar 10, 2020

craterbot commented Mar 10, 2020

craterbot commented Mar 10, 2020

eddyb commented Mar 12, 2020

estebank commented Mar 12, 2020

craterbot commented Mar 13, 2020

estebank commented Mar 14, 2020

estebank commented Mar 23, 2020

varkor commented Mar 26, 2020

Centril commented Mar 26, 2020

lcnr commented Mar 2, 2021

oli-obk commented Mar 2, 2021

oli-obk Mar 29, 2021 •

edited

Loading

nikomatsakis commented Apr 1, 2021

oli-obk commented Apr 1, 2021

nikomatsakis commented Apr 1, 2021

oli-obk commented Apr 1, 2021

nikomatsakis commented Apr 2, 2021

bors commented Apr 29, 2021

oli-obk commented May 3, 2021

nikomatsakis commented May 3, 2021 •

edited

Loading

oli-obk commented May 3, 2021

Dylan-DPC commented May 31, 2022

JohnCSimon commented Nov 27, 2022

		//pub type Foo = [i32; 0 - 1];
		//^ evaluation of constant value failed

Perform WF-check on types with no type parameters #69741

Perform WF-check on types with no type parameters #69741

Conversation

estebank commented Mar 5, 2020 • edited Loading

rust-highfive commented Mar 5, 2020

estebank commented Mar 5, 2020

estebank Mar 5, 2020

Choose a reason for hiding this comment

nikomatsakis commented Mar 9, 2020

estebank commented Mar 9, 2020

bors commented Mar 9, 2020

bors commented Mar 10, 2020

estebank commented Mar 10, 2020

craterbot commented Mar 10, 2020

craterbot commented Mar 10, 2020

eddyb commented Mar 12, 2020

estebank commented Mar 12, 2020

craterbot commented Mar 13, 2020

estebank commented Mar 14, 2020

estebank commented Mar 23, 2020

varkor commented Mar 26, 2020

Centril commented Mar 26, 2020

lcnr commented Mar 2, 2021

oli-obk commented Mar 2, 2021

oli-obk Mar 29, 2021 • edited Loading

Choose a reason for hiding this comment

nikomatsakis commented Apr 1, 2021

oli-obk commented Apr 1, 2021

nikomatsakis commented Apr 1, 2021

oli-obk commented Apr 1, 2021

nikomatsakis commented Apr 2, 2021

bors commented Apr 29, 2021

oli-obk commented May 3, 2021

nikomatsakis commented May 3, 2021 • edited Loading

oli-obk commented May 3, 2021

Dylan-DPC commented May 31, 2022

JohnCSimon commented Nov 27, 2022

Perform WF-check on `type`s with no type parameters #69741

Perform WF-check on `type`s with no type parameters #69741

estebank commented Mar 5, 2020 •

edited

Loading

oli-obk Mar 29, 2021 •

edited

Loading

nikomatsakis commented May 3, 2021 •

edited

Loading