Commit Graph

76 Commits

Author SHA1 Message Date
Michael Goulet
9a5936b814 Validate opaques in default trait bodies, don't normalize unless a body is provided 2022-10-05 04:16:09 +00:00
Michael Howell
55ebb61c68
Rollup merge of #102650 - Rageking8:slightly-improve-no-return-for-returning-function-error, r=compiler-errors
Slightly improve no return for returning function error

Fixes #100607

The rationale is that absolute beginners will be slightly confused as to why certain lines of code in a function does not require a semicolon. (I have actually witness a beginner having this confusion). Hence, a slight rationale is added "to return this value", which signals to the user that after removing said semicolon the value is returned resolving that error.

However, if this is not desirable, I welcome any other suggestions. Thanks.
2022-10-04 20:45:13 -07:00
Michael Goulet
28eda9b18a Suggest .into() when all other coercion suggestions fail 2022-10-05 02:47:31 +00:00
Oli Scherer
c7b6ebdf7c It's not about types or consts, but the lack of regions 2022-10-04 14:10:44 +00:00
yukang
e747201ad8 find the correct lang item for ranges 2022-10-04 21:02:07 +08:00
Rageking8
5ddaece650 slightly improve no return for returning function error 2022-10-04 19:13:40 +08:00
yukang
5dd44d4d4c fix #102396, suggest parentheses for possible range methods 2022-10-04 17:30:52 +08:00
Matthias Krüger
a2126e752f
Rollup merge of #102441 - chenyukang:fix-102320-unwrap_or_else, r=compiler-errors
Suggest unwrap_or_else when a closure is given

Fixes #102320

r? `@compiler-errors`
2022-10-04 06:14:10 +02:00
lcnr
550715d74d HirId for deferred_transmute_checks 2022-10-03 13:53:17 +02:00
yukang
01882733c9 fix #102320, suggest unwrap_or_else when a closure is passed to unwrap_or instead of suggesting calling it 2022-10-02 18:36:52 +08:00
Matthias Krüger
cc009bc536
Rollup merge of #102500 - compiler-errors:parse-sess-cleanup, r=cjgillot
Remove `expr_parentheses_needed` from `ParseSess`

Not sure why this method needed to exist on `ParseSess`, but we can achieve the same behavior by just inlining it everywhere.
2022-10-01 16:45:05 +02:00
bors
744e397d88 Auto merge of #101986 - WaffleLapkin:move_lint_note_to_the_bottom, r=estebank
Move lint level source explanation to the bottom

So, uhhhhh

r? `@estebank`

## User-facing change

"note: `#[warn(...)]` on by default" and such are moved to the bottom of the diagnostic:
```diff
-   = note: `#[warn(unsupported_calling_conventions)]` on by default
   = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
   = note: for more information, see issue #87678 <https://github.com/rust-lang/rust/issues/87678>
+   = note: `#[warn(unsupported_calling_conventions)]` on by default
```

Why warning is enabled is the least important thing, so it shouldn't be the first note the user reads, IMO.

## Developer-facing change

`struct_span_lint` and similar methods have a different signature.

Before: `..., impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>)`
After: `..., impl Into<DiagnosticMessage>, impl for<'a, 'b> FnOnce(&'b mut DiagnosticBuilder<'a, ()>) -> &'b mut DiagnosticBuilder<'a, ()>`

The reason for this is that `struct_span_lint` needs to edit the diagnostic _after_ `decorate` closure is called. This also makes lint code a little bit nicer in my opinion.

Another option is to use `impl for<'a> FnOnce(LintDiagnosticBuilder<'a, ()>) -> DiagnosticBuilder<'a, ()>` altough I don't _really_ see reasons to do `let lint = lint.build(message)` everywhere.

## Subtle problem

By moving the message outside of the closure (that may not be called if the lint is disabled) `format!(...)` is executed earlier, possibly formatting `Ty` which may call a query that trims paths that crashes the compiler if there were no warnings...

I don't think it's that big of a deal, considering that we move from `format!(...)` to `fluent` (which is lazy by-default) anyway, however this required adding a workaround which is unfortunate.

## P.S.

I'm sorry, I do not how to make this PR smaller/easier to review. Changes to the lint API affect SO MUCH 😢
2022-10-01 10:44:25 +00:00
Maybe Waffle
a8f7e244b7 Refactor rustc lint API 2022-10-01 10:03:06 +00:00
Boxy
c1a9cf42b4 make query take (LocalDefId, DefId) 2022-09-30 18:53:32 +01:00
Boxy
86a8a3beb4 make compare_const_impl a query and use it in instance.rs 2022-09-30 17:47:44 +01:00
Michael Goulet
85a726e754 Remove expr_parentheses_needed from ParseSess 2022-09-30 01:39:20 +00:00
bors
1bb8d276c9 Auto merge of #101887 - nnethercote:shrink-Res, r=spastorino
Shrink `hir::def::Res`

r? `@spastorino`
2022-09-29 22:45:24 +00:00
Oli Scherer
aa3fbf8795 Split out the error reporting logic into a separate function 2022-09-29 14:29:36 +00:00
Nicholas Nethercote
f07d4efc45 Shrink hir::def::Res.
`Res::SelfTy` currently has two `Option`s. When the second one is `Some`
the first one is never consulted. So we can split it into two variants,
`Res::SelfTyParam` and `Res::SelfTyAlias`, reducing the size of `Res`
from 24 bytes to 12. This then shrinks `hir::Path` and
`hir::PathSegment`, which are the HIR types that take up the most space.
2022-09-29 08:44:52 +10:00
bors
ce7f0f1aa0 Auto merge of #100719 - CohenArthur:rust-safe-intrinsic-attribute, r=wesleywiser
Add `#[rustc_safe_intrinsic]`

This PR adds the `#[rustc_safe_intrinsic]` attribute as mentionned on Zulip. The goal of this attribute is to avoid keeping a list of symbols as the source for stable intrinsics, and instead rely on an attribute. This is similar to `#[rustc_const_stable]` and `#[rustc_const_unstable]`, which among other things, are used to mark the constness of intrinsic functions.
2022-09-28 19:07:50 +00:00
Arthur Cohen
37bf8f888c rustc_safe_intrinsic: Keep list of safe intrinsics within the compiler 2022-09-28 09:40:02 +02:00
mejrs
4ff83cee95 Deduplicate some logic 2022-09-28 02:36:58 +02:00
mejrs
f3ac328d58 Address feedback 2022-09-27 21:42:09 +02:00
mejrs
c4c9415132 Wrapper suggestions 2022-09-27 21:42:09 +02:00
Arthur Cohen
0ab2c91a2d attributes: Add #[rustc_safe_intrinsic] builtin 2022-09-27 15:55:42 +02:00
lcnr
1fc86a63f4 rustc_typeck to rustc_hir_analysis 2022-09-27 10:37:23 +02:00