Commit Graph

1458 Commits

Author SHA1 Message Date
bors
3b3f3b72c5 Auto merge of #100989 - lcnr:implied-bounds-uwu, r=spastorino
no unnormalized types for implied bounds outside borrowck

fixes #100910 - introduced in https://github.com/rust-lang/rust/pull/100676 - by only considering normalized types for wf.

r? types
2022-08-27 11:37:06 +00:00
ouz-a
36faf8fc7e Don't catch overflow when running with cargo doc 2022-08-26 21:02:35 +03:00
bors
983f4daddf Auto merge of #100705 - compiler-errors:issue-100620, r=oli-obk
Avoid reporting overflow in `is_impossible_method`

Fixes #100620

We're evaluating a new predicate in a different param-env than it was checked during typeck, so be more careful about handling overflow errors. Instead of using `FulfillmentCtxt`, using `InferCtxt::evaluate_obligation` by itself will give us back the overflow error, so we can throw it away properly.

This may give us more false-positives, but it doesn't regress the `<HashMap as Iterator>::rev` example that originally motivated adding `is_impossible_method` in the first place.
2022-08-26 06:05:06 +00:00
lcnr
ef7bda3b62 no unnormalized types for implied bounds 2022-08-25 11:12:04 +02:00
Yuki Okushi
f4550a6edf
Rollup merge of #99332 - jyn514:stabilize-label-break-value, r=petrochenkov
Stabilize `#![feature(label_break_value)]`

See the stabilization report in https://github.com/rust-lang/rust/issues/48594#issuecomment-1186213313.
2022-08-25 08:50:54 +09:00
Matthias Krüger
0fcabec620
Rollup merge of #100888 - spastorino:coherence-negative-impls-implied-bounds, r=lcnr
Coherence negative impls implied bounds

Fixes #93875

This PR is rebased on top of #100789 and it would need to include that one which is already r+ed.

r? ``@nikomatsakis``

cc ``@lcnr`` (which I've talked about 3222f420d9, I guess after you finish your reordering of modules and work with OutlivesEnvironmentEnv this commit can just be reverted).
2022-08-24 18:20:11 +02:00
Joshua Nelson
31e39446ec Stabilize #![feature(label_break_value)]
# Stabilization proposal

The feature was implemented in https://github.com/rust-lang/rust/pull/50045 by est31 and has been in nightly since 2018-05-16 (over 4 years now).
There are [no open issues][issue-label] other than the tracking issue. There is a strong consensus that `break` is the right keyword and we should not use `return`.

There have been several concerns raised about this feature on the tracking issue (other than the one about tests, which has been fixed, and an interaction with try blocks, which has been fixed).
1. nrc's original comment about cost-benefit analysis: https://github.com/rust-lang/rust/issues/48594#issuecomment-422235234
2. joshtriplett's comments about seeing use cases: https://github.com/rust-lang/rust/issues/48594#issuecomment-422281176
3. withoutboats's comments that Rust does not need more control flow constructs: https://github.com/rust-lang/rust/issues/48594#issuecomment-450050630

Many different examples of code that's simpler using this feature have been provided:
- A lexer by rpjohnst which must repeat code without label-break-value: https://github.com/rust-lang/rust/issues/48594#issuecomment-422502014
- A snippet by SergioBenitez which avoids using a new function and adding several new return points to a function: https://github.com/rust-lang/rust/issues/48594#issuecomment-427628251. This particular case would also work if `try` blocks were stabilized (at the cost of making the code harder to optimize).
- Several examples by JohnBSmith: https://github.com/rust-lang/rust/issues/48594#issuecomment-434651395
- Several examples by Centril: https://github.com/rust-lang/rust/issues/48594#issuecomment-440154733
- An example by petrochenkov where this is used in the compiler itself to avoid duplicating error checking code: https://github.com/rust-lang/rust/issues/48594#issuecomment-443557569
- Amanieu recently provided another example related to complex conditions, where try blocks would not have helped: https://github.com/rust-lang/rust/issues/48594#issuecomment-1184213006

Additionally, petrochenkov notes that this is strictly more powerful than labelled loops due to macros which accidentally exit a loop instead of being consumed by the macro matchers: https://github.com/rust-lang/rust/issues/48594#issuecomment-450246249

nrc later resolved their concern, mostly because of the aforementioned macro problems.
joshtriplett suggested that macros could be able to generate IR directly
(https://github.com/rust-lang/rust/issues/48594#issuecomment-451685983) but there are no open RFCs,
and the design space seems rather speculative.

joshtriplett later resolved his concerns, due to a symmetry between this feature and existing labelled break: https://github.com/rust-lang/rust/issues/48594#issuecomment-632960804

withoutboats has regrettably left the language team.

joshtriplett later posted that the lang team would consider starting an FCP given a stabilization report: https://github.com/rust-lang/rust/issues/48594#issuecomment-1111269353

[issue-label]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label%3AF-label_break_value+

 ## Report

+ Feature gate:
    - d695a497bb/src/test/ui/feature-gates/feature-gate-label_break_value.rs
+ Diagnostics:
    - 6b2d3d5f3c/compiler/rustc_parse/src/parser/diagnostics.rs (L2629)
    - f65bf0b2bb/compiler/rustc_resolve/src/diagnostics.rs (L749)
    - f65bf0b2bb/compiler/rustc_resolve/src/diagnostics.rs (L1001)
    - 111df9e6ed/compiler/rustc_passes/src/loops.rs (L254)
    - d695a497bb/compiler/rustc_parse/src/parser/expr.rs (L2079)
    - d695a497bb/compiler/rustc_parse/src/parser/expr.rs (L1569)
+ Tests:
    - https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_continue.rs
    - https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_unlabeled_break.rs
    - https://github.com/rust-lang/rust/blob/master/src/test/ui/label/label_break_value_illegal_uses.rs
    - https://github.com/rust-lang/rust/blob/master/src/test/ui/lint/unused_labels.rs
    - https://github.com/rust-lang/rust/blob/master/src/test/ui/run-pass/for-loop-while/label_break_value.rs

 ## Interactions with other features

Labels follow the hygiene of local variables.

label-break-value is permitted within `try` blocks:
```rust
let _: Result<(), ()> = try {
    'foo: {
        Err(())?;
        break 'foo;
    }
};
```

label-break-value is disallowed within closures, generators, and async blocks:
```rust
'a: {
    || break 'a
    //~^ ERROR use of unreachable label `'a`
    //~| ERROR `break` inside of a closure
}
```

label-break-value is disallowed on [_BlockExpression_]; it can only occur as a [_LoopExpression_]:
```rust
fn labeled_match() {
    match false 'b: { //~ ERROR block label not supported here
        _ => {}
    }
}

macro_rules! m {
    ($b:block) => {
        'lab: $b; //~ ERROR cannot use a `block` macro fragment here
        unsafe $b; //~ ERROR cannot use a `block` macro fragment here
        |x: u8| -> () $b; //~ ERROR cannot use a `block` macro fragment here
    }
}

fn foo() {
    m!({});
}
```

[_BlockExpression_]: https://doc.rust-lang.org/nightly/reference/expressions/block-expr.html
[_LoopExpression_]: https://doc.rust-lang.org/nightly/reference/expressions/loop-expr.html
2022-08-23 21:14:12 -05:00
Dylan DPC
f42cdf76e1
Rollup merge of #100368 - chenyukang:fix-100321, r=lcnr
InferCtxt tainted_by_errors_flag should be Option<ErrorGuaranteed>

Fixes #100321.
Use Cell<Option<ErrorGuaranteed>> to guarantee that we emit an error when that flag is set.
2022-08-23 20:40:03 +05:30
Santiago Pastorino
4da14ef50e
Use CRATE_HIR_ID and CRATE_DEF_ID for obligations from foreign crates 2022-08-23 09:08:30 -03:00
Santiago Pastorino
4cb492e740
Do not use unneeded extra errors variable 2022-08-23 08:55:43 -03:00
Santiago Pastorino
ac0b6af37b
Permit negative impls coherence to take advantage of implied bounds 2022-08-23 08:55:43 -03:00
Santiago Pastorino
5ff45dc89e
Move InferCtxtExt to rustc_trait_selection 2022-08-23 08:55:43 -03:00
Matthias Krüger
579dfa42be
Rollup merge of #100789 - compiler-errors:issue-99662, r=spastorino
Use separate infcx to solve obligations during negative coherence

I feel like I fixed this already but I may have fixed it then forgot to push the branch...

Also fixes up some redundant param-envs being passed around (since they're already passed around in the `Obligation`)

Fixes #99662

r? ``@spastorino``
2022-08-23 06:55:26 +02:00
yukang
f466a7563d remove hack fix since we don't have no overflow diagnostic 2022-08-22 22:22:15 +08:00
bors
ee8c31e64d Auto merge of #100868 - Dylan-DPC:rollup-a1hfi1r, r=Dylan-DPC
Rollup of 5 pull requests

Successful merges:

 - #93162 (Std module docs improvements)
 - #99386 (Add tests that check `Vec::retain` predicate execution order.)
 - #99915 (Recover keywords in trait bounds)
 - #100694 (Migrate rustc_ast_passes diagnostics to `SessionDiagnostic` and translatable messages (first part))
 - #100757 (Catch overflow early)

Failed merges:

 - #99917 (Move Error trait into core)

r? `@ghost`
`@rustbot` modify labels: rollup
2022-08-22 08:32:41 +00:00
Dylan DPC
88e39b2c2e
Rollup merge of #100757 - ouz-a:issue-95134, r=jackh726
Catch overflow early

Although this code should raise an overflow error, it didn't because [check_recursion_limit](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/traits/select/struct.SelectionContext.html#method.check_recursion_limit) it checks for `depth = 128` but not for `129` which should have triggered the overflow error. Anyways this catches that error early.

Fixes #95134
2022-08-22 11:45:45 +05:30
bors
a9bb589cd6 Auto merge of #100676 - lcnr:implied-bounds-yay, r=nikomatsakis
implied bounds: explicitly state which types are assumed to be wf

Adds a new query which maps each definition to the types which that definition assumes to be well formed. The intent is to make it easier to reason about implied bounds.

This change should not influence the user-facing behavior of rustc. Notably, `borrowck` still only assumes that the function signature of associated functions is well formed while `wfcheck` assumes that the both the function signature and the impl trait ref is well formed. Not sure if that by itself can trigger UB or whether it's just annoying.

As a next step, we can add `WellFormed` predicates to `predicates_of` of these items and can stop adding the wf bounds at each place which uses them. I also intend to move the computation from `assumed_wf_types` to `implied_bounds` into the `param_env` computation. This requires me to take a deeper look at `compare_predicate_entailment` which is currently somewhat weird wrt implied bounds so I am not touching this here.

r? `@nikomatsakis`
2022-08-22 06:10:26 +00:00
Michael Goulet
d577eb09e5 Bless tests after #100769 2022-08-21 04:04:05 +00:00
Michael Goulet
d2f54b1990 Adjust messages, address some nits 2022-08-21 02:35:11 +00:00
Michael Goulet
8917894fda Targeted fixes addressing erroneous suggestions 2022-08-21 02:35:11 +00:00
Michael Goulet
70b29f7c2d Note closure kind mismatch cause 2022-08-21 02:35:11 +00:00
Michael Goulet
c005e760f5 Rework point-at-arg 2022-08-21 02:34:52 +00:00
Matthias Krüger
d793cd266c
Rollup merge of #100796 - TaKO8Ki:remove-unnecessary-string-searching, r=compiler-errors
Refactor: remove unnecessary string searchings

This patch removes unnecessary string searchings for checking if function arguments have `&` and `&mut`.
2022-08-20 19:45:17 +02:00
Matthias Krüger
7f0289623c
Rollup merge of #100769 - TaKO8Ki:suggest-adding-reference-to-trait-assoc-item, r=cjgillot
Suggest adding a reference to a trait assoc item

fixes #100289
2022-08-20 19:45:15 +02:00
Takayuki Maeda
a311b8a4c5 use more descriptive names 2022-08-20 19:35:17 +09:00
Takayuki Maeda
973510749d remove unnecessary string searchings
remove unnecessary string searchings for checking if function arguments have `&` and `&mut`
2022-08-20 15:54:39 +09:00
Michael Goulet
ba7272959d Use separate infcx to solve obligations during negative coherence 2022-08-20 04:49:24 +00:00
Takayuki Maeda
64b3e4af20 suggest adding a reference to a trait assoc item 2022-08-20 02:51:20 +09:00
ouz-a
c198a20f7c Catch overflow early 2022-08-19 17:31:57 +03:00
Andy Wang
84a199369b
Reword "Required because of the requirements on the impl of ..." 2022-08-18 21:08:08 +01:00
bors
8064a49508 Auto merge of #99860 - oli-obk:revert_97346, r=pnkfelix
Revert "Rollup merge of #97346 - JohnTitor:remove-back-compat-hacks, …

…r=oli-obk"

This reverts commit c703d11dcc, reversing
changes made to 64eb9ab869.

it didn't apply cleanly, so now it works the same for RPIT and for TAIT instead of just working for RPIT, but we should keep those in sync anyway. It also exposed a TAIT bug (see the feature gated test that now ICEs).

r? `@pnkfelix`

fixes #99536
2022-08-18 15:41:30 +00:00
Michael Goulet
c4a5b14211 Avoid overflow in is_impossible_method 2022-08-18 01:12:46 +00:00
lcnr
736288f221 dedup some code 2022-08-17 18:14:25 +02:00
lcnr
1cede2c126 is_knowable use Result instead of Option 2022-08-17 10:17:54 +02:00
Michael Goulet
8b64988575 Fix error message with non-tupled bare fn trait 2022-08-16 01:21:11 +00:00
Matthias Krüger
a1fdea2b78
Rollup merge of #100514 - compiler-errors:issue-100191, r=spastorino
Delay span bug when failing to normalize negative coherence impl subject due to other malformed impls

Fixes #100191

r? ``@spastorino``
2022-08-15 20:11:36 +02:00
Michael Goulet
75dfe55a5d TypeError can be Copy 2022-08-14 19:58:46 +00:00
Dylan DPC
92344e369b
Rollup merge of #99861 - lcnr:orphan-check-cg, r=jackh726
orphan check: rationalize our handling of constants

cc `@rust-lang/types` `@rust-lang/project-const-generics` on whether you agree with this reasoning.

r? types
2022-08-14 17:09:13 +05:30
Michael Goulet
c436930f91 Delay span bug when failing to normalize negative coherence impl subject due to other malformed impls 2022-08-13 22:11:42 +00:00
lcnr
1ec2b9bce8 wf correctly shallow_resolve consts 2022-08-13 21:04:52 +02:00
Mark Rousskov
154a09dd91 Adjust cfgs 2022-08-12 16:28:15 -04:00
bors
aeb5067967 Auto merge of #100315 - compiler-errors:norm-ct-in-proj, r=lcnr
Keep going if normalized projection has unevaluated consts in `QueryNormalizer`

#100312 was the wrong approach, I think this is the right one.

When normalizing a type, if we see that it's a projection, we currently defer to `tcx.normalize_projection_ty`, which normalizes the projections away but doesn't touch the unevaluated constants. So now we just continue to fold the type if it has unevaluated constants so we make sure to evaluate those too, if we can.

Fixes #100217
Fixes #83972
Fixes #84669
Fixes #86710
Fixes #82268
Fixes #73298
2022-08-11 10:47:48 +00:00
Michael Goulet
d2667e4b71 Move folding into just projection cases 2022-08-09 18:19:58 +00:00
bors
63e4312e6b Auto merge of #99217 - lcnr:implied-bounds-pre-norm, r=lcnr
consider unnormalized types for implied bounds

extracted, and slightly modified, from #98900

The idea here is that generally, rustc is split into things which can assume its inputs are well formed[^1], and things which have verify that themselves.

Generally most predicates should only deal with well formed inputs, e.g. a `&'a &'b (): Trait` predicate should be able to assume that `'b: 'a` holds. Normalization can loosen wf requirements (see #91068) and must therefore not be used in places which still have to check well formedness. The only such place should hopefully be `WellFormed` predicates

fixes #87748 and #98543

r? `@jackh726` cc `@rust-lang/types`

[^1]: These places may still encounter non-wf inputs and have to deal with them without causing an ICE as we may check for well formedness out of order.
2022-08-09 16:39:43 +00:00
Dylan DPC
d910e5376b
Rollup merge of #100221 - compiler-errors:impossible-trait-items, r=lcnr,notriddle,camelid
Don't document impossible to call default trait items on impls

Closes #100176

This only skips documenting _default_ trait items on impls, not ones that are written inside the impl block. This is a conservative approach, since I think we should document all items written in an impl block (I guess unless hidden or whatever), but the existence of this new query I added makes this easy to extend to other rustdoc cases.
2022-08-09 17:34:54 +05:30
lcnr
f25cb83296 don't normalize wf predicates
this allows us to soundly use unnormalized projections for wf
2022-08-09 12:54:32 +02:00
Michael Goulet
ca7e3c4a83 Keep going if normalized projection has unevaluated consts in QueryNormalizer 2022-08-09 09:41:28 +00:00
Michael Goulet
3fdf3cb80c Adjust wording 2022-08-08 00:13:41 +00:00
Michael Goulet
750f04d309 Implement special-cased projection error message for some common traits 2022-08-07 23:57:53 +00:00
Michael Goulet
b3b23aada9 Don't document impossible to call default trait items on impls 2022-08-07 23:44:05 +00:00