| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This fixes #35849, a regression introduced by the typeck refactoring
around TyNever/!.
|
|
Fix incorrect unused import warnings on `cfg_attr`ed `path` attributes
Fixes #35584.
r? @eddyb
|
|
Implement the `!` type
This implements the never type (`!`) and hides it behind the feature gate `#[feature(never_type)]`. With the feature gate off, things should build as normal (although some error messages may be different). With the gate on, `!` is usable as a type and diverging type variables (ie. types that are unconstrained by anything in the code) will default to `!` instead of `()`.
|
|
Err codes
r? @jonathandturner
|
|
|
|
Update E0261 and E0262 to new error format
Fixes #35516 and #35517 . Part of #35233
r? @jonathandturner
|
|
E0094 error message updated
Part of #35233
Fixes #35231
r? @jonathandturner
|
|
r=jonathandturner
Update E0302 to the new format
Part of #35233.
Fixes #35523.
r? @jonathandturner
|
|
r=jonathandturner
Update E0301 to the new format
Part of #35233.
Fixes #35522.
r? @jonathandturner
|
|
changed E0067 to new error format
Updated E0067 to new error format.
Part of #35233
Fixes #35502
Passes all the tests when running:
`python src/bootstrap/bootstrap.py --step check-cfail --stage 1`
**This seems strange, given that the format for E0067 has been changed.**
It feels like it should fail some unit tests maybe?
Let me know if I'm mistaken. Otherwise I can create a unit test for it.
Thanks for letting me help!
r? @jonathandturner
|
|
Update E0070 to new error format
Updated E0070 to new error format.
Part of #35233
Fixes #35503
Thanks for letting me help!
r? @jonathandturner
|
|
Improve &-ptr printing
This PR replaces printing `&-ptr` with a more readable description. To do so it uses a few heuristics.
If the name of the type is unknown, too long (longer than just saying "reference"), or too complex (a type with explicit lifetime annotations), it will instead opt to print either "reference" or "mutable reference", depending on the mutability of the type.
Before:
```
error[E0308]: mismatched types
--> src/test/compile-fail/issue-7061.rs:14:46
|
14 | fn foo(&'a mut self) -> Box<BarStruct> { self }
| ^^^^ expected box, found &-ptr
|
= note: expected type `Box<BarStruct>`
= note: found type `&'a mut BarStruct`
error: aborting due to previous error
```
After:
```
error[E0308]: mismatched types
--> src/test/compile-fail/issue-7061.rs:14:46
|
14 | fn foo(&'a mut self) -> Box<BarStruct> { self }
| ^^^^ expected box, found mutable reference
|
= note: expected type `Box<BarStruct>`
= note: found type `&'a mut BarStruct`
error: aborting due to previous error
```
|
|
r=jonathandturner
Add label to E0254
This issue #35513 is a part of #35233.
r? @jonathandturner
|
|
E0248, E0267 & E0268 Change into issue format
r? @jonathandturner Part of #35391, #35519 and #35520. I have squashed all changes into a single commit. Please review the changes.
E0248 Change in issue format
E0267 UT New Format
E0268 UT New Format
E0267 & E0268 New Error Format
|
|
Update E0138 to new format
Part of #35233
Fix #35510
r? @jonathandturner
Question: How can I only underline the function name ? I have observed the debug output and the struct of item, but I can't find the `Span` for function name. Should I modify the struct I get to save function name's position or there is another way to get it ? (I can only find `Span`s for function attributes, inputs, outputs, blocks)
|
|
Update error message for E0253 #35512
Fixes #35512. Part of #35233.
|
|
Correct span for pub_restricted field
Fix #35435.
|
|
Make `private_in_public` compatibility lint deny-by-default
In accordance with the [plan](https://internals.rust-lang.org/t/fcp-for-various-future-compatibility-warnings/3590/5?u=petrochenkov).
r? @nikomatsakis
|
|
|
|
macros: Make metavariables hygienic
This PR makes metavariables hygienic. For example, consider:
```rust
macro_rules! foo {
($x:tt) => { // Suppose that this token tree argument is always a metavariable.
macro_rules! bar { ($x:expr, $y:expr) => { ($x, $y) } }
}
}
fn main() {
foo!($z); // This currently compiles.
foo!($y); // This is an error today but compiles after this PR.
}
```
Today, the `macro_rules! bar { ... }` definition is only valid when the metavariable passed to `foo` is not `$y` (since it unhygienically conflicts with the `$y` in the definition of `bar`) or `$x` (c.f. #35450).
After this PR, the definition of `bar` is always valid (and `bar!(a, b)` always expands to `(a, b)` as expected).
This can break code that was allowed in #34925 (landed two weeks ago). For example,
```rust
macro_rules! outer {
($t:tt) => {
macro_rules! inner { ($i:item) => { $t } }
}
}
outer!($i); // This `$i` should not interact with the `$i` in the definition of `inner!`.
inner!(fn main() {}); // After this PR, this is an error ("unknown macro variable `i`").
```
Due to the severe limitations on nested `macro_rules!` before #34925, this is not a breaking change for stable/beta.
Fixes #35450.
r? @nrc
|
|
|
|
|
|
|
|
|
|
|
|
These tests check for the old error messages "`return` in a function
declared as diverging" and "computation may converge in a function
declared as diverging". The first of these is now invalid as `return` is
permitted in functions that return `!`. The second of these is subsumed
by the "mismatched types" error.
|
|
Part of #35233
Fixes #35231
|
|
|
|
Implement RFC 1506 "Clarify the relationships between various kinds of structs and variants"
cc https://github.com/rust-lang/rust/issues/35626
|
|
|
|
|
|
|
|
Hard errors are turned into feature gates
|
|
|
|
Err codes
r? @jonathandturner
|
|
|
|
|
|
|
|
|
|
|
|
Fixes #28514
|
|
|
|
Rollup of 23 pull requests
- Successful merges: #35279, #35331, #35358, #35375, #35445, #35448, #35482, #35486, #35505, #35528, #35530, #35532, #35536, #35537, #35541, #35552, #35554, #35555, #35557, #35562, #35565, #35569, #35576
- Failed merges: #35395, #35415, #35563
|
|
|
|
This issue #35513 is a part of #35233.
r? @jonathandturner
|
|
E0072 update error format
Part of #35233
Fixes #35506
r? @jonathandturner
The bonus for this issue currently seems to be impossible to do reliably, as the compiler seems to lack span information for item names alone, like `Foo` in `struct Foo { ... }`. It would be possible to hack something together by computing span offsets, but that seems like a solution that would be begging for trouble.
A proper solution to this would, of course, be to add span information to the right place (seems to be `rustc::hir::Item::name` but I may be wrong).
|
|
Update E0133 to new format
Part of #35233
Fix #35509
r? @jonathandturner
|
|
E0263 updated to new format.
Fixes #35518. Part of #35233.
r? @jonathandturner
|
|
E0128 update error format
Fixes #35508
Part of #35233
r? @jonathandturner
|
