nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-11-30 10:45:18 +00:00
Code Issues Packages Projects Releases Wiki Activity
220,027 Commits 7 Branches 140 Tags 1.8 GiB
9139ed076d
Commit Graph

43 Commits

Author SHA1 Message Date
Matthias Krüger
36b82373e0
Rollup merge of #109158 - Ezrashaw:expand-sugg-for-unused-lint, r=Nilstrieb 
error-msg: expand suggestion for `unused_def` lint

Fixes #108885

Expands `let _ = ..` suggestion into more positions.
 2023-03-16 08:57:07 +01:00
Ezra Shaw
35103fe8ab
error-msg: expand suggestion for unused lint 2023-03-15 23:30:12 +13:00
yukang
b3af5e2f8b Fix #109152, fix the scenario that we may can not get span of func 2023-03-15 14:07:39 +08:00
Matthias Krüger
fbc121fdfd
Rollup merge of #104363 - WaffleLapkin:bonk_box_new, r=Nilstrieb 
Make `unused_allocation` lint against `Box::new` too

Previously it only linted against `box` syntax, which likely won't ever be stabilized, which is pretty useless. Even now I'm not sure if it's a meaningful lint, but it's at least something 🤷

This means that code like the following will be linted against:
```rust
Box::new([1, 2, 3]).len();
f(&Box::new(1)); // where f : &i32 -> ()
```
The lint works by checking if a `Box::new` (or `box`) expression has an a borrow adjustment, meaning that the code that first stores the box in a variable won't be linted against:
```rust
let boxed = Box::new([1, 2, 3]); // no lint
boxed.len();
```
 2023-03-11 15:43:11 +01:00
Albert Larsan
33d7fad7e5
Add regression test for 98444 2023-03-06 13:41:07 +00:00
Maybe Waffle
a90abd64fb Remove feature(box_syntax) from unused allocation list test 2023-03-03 19:02:35 +00:00
Maybe Waffle
ff5f784140 Add a test for unused_allocation lint 
(how come we didn't have one already??)
 2023-03-03 17:47:40 +00:00
Matthias Krüger
371904bba6
Rollup merge of #108297 - chenyukang:yukang/delim-error-exit, r=petrochenkov 
Exit when there are unmatched delims to avoid noisy diagnostics

From https://github.com/rust-lang/rust/pull/104012#issuecomment-1311764832
r? ``@petrochenkov``
 2023-03-01 01:20:22 +01:00
yukang
65ad5f8de7 remove duplicated diagnostic for unclosed delimiter 2023-02-28 07:57:17 +00:00
yukang
f01d0c02e7 Exit when there are unmatched delims to avoid noisy diagnostics 2023-02-28 07:55:19 +00:00
Obei Sideg
99344a8b32 Add ui test for E0271 error 2023-02-23 13:57:13 +03:00
Obei Sideg
b93d54556f Add ui test for map_unit_fn lint in closure case 2023-02-23 13:57:13 +03:00
Obei Sideg
ddd7d10879 Add ui test for map_unit_fn lint 2023-02-23 13:57:13 +03:00
bors
0978711950 Auto merge of #108324 - notriddle:notriddle/assoc-fn-method, r=compiler-errors,davidtwco,estebank,oli-obk 
diagnostics: if AssocFn has self argument, describe as method

Discussed in https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics/topic/.22associated.20function.22.20vs.20.22method.22/near/329265515

This commit also changes the tooltips on rustdoc intra-doc links targeting methods.

For anyone not sure why this is being done, see the Reference definitions of these terms in <https://doc.rust-lang.org/1.67.1/reference/items/associated-items.html#methods>

> Associated functions whose first parameter is named `self` are called methods and may be invoked using the [method call operator](https://doc.rust-lang.org/1.67.1/reference/expressions/method-call-expr.html), for example, `x.foo()`, as well as the usual function call notation.

In particular, while this means it's technically correct for rustc to refer to a method as an associated function (and there are a few cases where it'll still do so), rustc *must never* use the term "method" to refer to an associated function that does not have a `self` parameter.
 2023-02-23 00:19:12 +00:00
Michael Howell
3f374128ee diagnostics: update test cases to refer to assoc fn with self as method 2023-02-22 08:40:47 -07:00
clubby789
c7a4f387fd Lint dead code in closures 2023-02-22 15:27:19 +00:00
Dylan DPC
4dea3a295f
Rollup merge of #108000 - y21:no-zero-init-for-uninhabited, r=jackh726 
lint: don't suggest MaybeUninit::assume_init for uninhabited types

Creating a zeroed uninhabited type such as `!` or an empty enum with `mem::zeroed()` (or transmuting `()` to `!`) currently triggers this lint:
```rs
warning: the type `!` does not permit zero-initialization
 --> test.rs:5:23
  |
5 |         let _val: ! = mem::zeroed();
  |                       ^^^^^^^^^^^^^
  |                       |
  |                       this code causes undefined behavior when executed
  |                       help: use `MaybeUninit<T>` instead, and only call `assume_init` after initialization is done
  |
  = note: the `!` type has no valid value
```
The `MaybeUninit` suggestion in the help message seems confusing/useless for uninhabited types, as such a type cannot be fully initialized in the first place (as the note implies).
This PR limits this help message to inhabited types which can be initialized
 2023-02-21 14:19:58 +05:30
bors
21e5b941e0 Auto merge of #108128 - clubby789:builtin-derived-attr, r=jackh726 
Properly check for builtin derived code

Fixes #108122
 2023-02-19 21:18:07 +00:00
y21
0610df9314 lint: don't suggest assume_init for uninhabited types 2023-02-18 19:05:44 +01:00
clubby789
eebd31c187 Don't eagerly convert principal to string 2023-02-17 14:44:58 +00:00
clubby789
90f642bb3d Properly check for builtin derives 2023-02-16 19:44:03 +00:00
Michael Goulet
087a0136d0 Don't ICE in might_permit_raw_init if reference is polymorphic 2023-02-14 01:03:06 +00:00
Matthias Krüger
8fc9ed51f0
Rollup merge of #107043 - Nilstrieb:true-and-false-is-false, r=wesleywiser 
Support `true` and `false` as boolean flag params

Implements [MCP 577](https://github.com/rust-lang/compiler-team/issues/577).
 2023-02-10 06:09:56 +01:00
bors
044a28a409 Auto merge of #103761 - chenyukang:yukang/fix-103320-must-use, r=compiler-errors 
Add explanatory message for [#must_use] in ops

Fixes #103320
 2023-02-06 12:57:37 +00:00
Dylan DPC
d9db35785d
Rollup merge of #107539 - PossiblyAShrub:unused-parens-in-index, r=lcnr 
Emit warnings on unused parens in index expressions

Fixes: #96606.

I am not sure what the best term for "index expression" is. Is there a better term we could use?
 2023-02-03 23:04:51 +05:30
yukang
cb55d10eb2 Fix #103320, add explanatory message for [#must_use] 2023-02-04 00:27:03 +08:00
Aidan Olsen
c3a71ede7c Emit warnings on unused parens/braces in index expressions 2023-02-02 12:46:31 -07:00
Ralf Jung
dfc4a7b2d0 make unaligned_reference a hard error 2023-01-31 20:28:11 +01:00
Esteban Küber
62ba3e70a1 Modify primary span label for E0308 
The previous output was unintuitive to users.
 2023-01-30 20:12:19 +00:00
Camille GILLOT
0e52a671d4 Bless tests. 2023-01-27 20:10:17 +00:00
Camille GILLOT
9259da51ed Test the 3 generator handling versions for generator/async tests. 2023-01-27 18:58:13 +00:00
Aaron Hill
dc8876196b
Add SEMICOLON_IN_EXPRESSIONS_FROM_MACROS to future-incompat report 2023-01-21 14:38:25 -06:00
--global
734f375019 Change bindings_with_variant_name to deny-by-default 2023-01-20 02:26:12 -05:00
Nilstrieb
a6fda3ee7f Support true and false as boolean flag params 
Implements MCP 577.
 2023-01-18 20:46:36 +01:00
Dylan DPC
f91f369949
Rollup merge of #106148 - chenyukang:yukang/fix-105061-unused, r=lcnr 
Fix unused_parens issue for higher ranked function pointers

fixes #105061

r? `@lcnr`
 2023-01-17 20:33:03 +05:30
yukang
9d74bb832f comments feedback 2023-01-16 20:44:14 +08:00
clubby789
295f5483fe Fix regression in unused_braces with macros 2023-01-15 05:08:30 +00:00
yukang
644ee8d250 add test case for issue 105601 2023-01-14 17:11:05 +08:00
yukang
7d99866bfc fix #105061, Fix unused_parens issue for higher ranked function pointers 2023-01-14 17:11:04 +08:00
Matthias Krüger
c6e3a47843
Rollup merge of #106585 - estebank:issue-46585, r=compiler-errors 
When suggesting writing a fully qualified path probe for appropriate types

Address the more common part of #46585.
 2023-01-13 19:16:42 +01:00
Arthur Carcano
797f247997 Mark ZST as FFI-safe if all its fields are PhantomData 
Modify the linting behavior and add the corresponding
regression test
 2023-01-12 12:21:35 +01:00
Esteban Küber
12ddf77811 When suggesting writing a fully qualified path probe for appropriate types 
Fix #46585.
 2023-01-11 21:30:10 +00:00
Albert Larsan
cf2dff2b1e
Move /src/test to /tests 2023-01-11 09:32:08 +00:00