Part of #24407.
Currently the diagnostics for range patterns are a bit wrong:
```rust
fn main() {
match 5u32 {
0 ... 10 => (),
'a' ... 10 => (),
10 ... 'z' => (),
"what" ... 10 => (),
"what" ... "well" => (),
10 ... "what" => ()
}
}
```
```
range.rs:4:9: 4:19 error: mismatched types in range:
expected integral variable,
found char [E0211]
range.rs:4 'a' ... 10 => (),
^~~~~~~~~~
range.rs:4:9: 4:16 error: only char and numeric types are allowed in range [E0029]
range.rs:4 'a' ... 10 => (),
^~~~~~~
range.rs:4:9: 4:19 error: mismatched types:
expected `u32`,
found `char`
(expected u32,
found char) [E0308]
range.rs:4 'a' ... 10 => (),
^~~~~~~~~~
range.rs:5:9: 5:19 error: mismatched types in range:
expected char,
found integral variable [E0211]
range.rs:5 10 ... 'z' => (),
^~~~~~~~~~
range.rs:5:9: 5:15 error: only char and numeric types are allowed in range [E0029]
range.rs:5 10 ... 'z' => (),
^~~~~~
range.rs:6:9: 6:22 error: mismatched types in range:
expected integral variable,
found &-ptr [E0211]
range.rs:6 "what" ... 10 => (),
^~~~~~~~~~~~~
range.rs:6:9: 6:19 error: only char and numeric types are allowed in range [E0029]
range.rs:6 "what" ... 10 => (),
^~~~~~~~~~
range.rs:6:9: 6:22 error: mismatched types:
expected `u32`,
found `&'static str`
(expected u32,
found &-ptr) [E0308]
range.rs:6 "what" ... 10 => (),
^~~~~~~~~~~~~
range.rs:7:9: 7:19 error: only char and numeric types are allowed in range [E0029]
range.rs:7 "what" ... "well" => (),
^~~~~~~~~~
range.rs:7:9: 7:26 error: mismatched types:
expected `u32`,
found `&'static str`
(expected u32,
found &-ptr) [E0308]
range.rs:7 "what" ... "well" => (),
^~~~~~~~~~~~~~~~~
range.rs:8:9: 8:22 error: mismatched types in range:
expected &-ptr,
found integral variable [E0211]
range.rs:8 10 ... "what" => ()
^~~~~~~~~~~~~
range.rs:8:9: 8:15 error: only char and numeric types are allowed in range [E0029]
range.rs:8 10 ... "what" => ()
^~~~~~
error: aborting due to 12 previous errors
```
The problems here are:
1. The type of the end of the range is used to predict the type of the start (only mildly counter intuitive).
2. E0029 is erroneously generated for `char ... num` and `num ... char`.
2. `u32` is mentioned.
3. Errors which are essentially the same are reported multiple times.
I've attempted to fix this by checking the requirements in a different order. The output I've achieved for the above example is:
```
/home/michael/Temp/range.rs:4:17: 4:22 error: mismatched types in range:
expected char,
found integral variable [E0211]
/home/michael/Temp/range.rs:4 'a' ... 10 => (),
^~~~~
/home/michael/Temp/range.rs:5:16: 5:22 error: mismatched types in range:
expected integral variable,
found char [E0211]
/home/michael/Temp/range.rs:5 10 ... 'z' => (),
^~~~~~
/home/michael/Temp/range.rs:6:9: 6:19 error: only char and numeric types are allowed in range [E0029]
/home/michael/Temp/range.rs:6 "what" ... 10 => (),
^~~~~~~~~~
/home/michael/Temp/range.rs:6:9: 6:19 help: run `rustc --explain E0029` to see a detailed explanation
/home/michael/Temp/range.rs:6:9: 6:19 note: Start type: &'static str
End type: _
/home/michael/Temp/range.rs:6 "what" ... 10 => (),
^~~~~~~~~~
/home/michael/Temp/range.rs:7:9: 7:26 error: only char and numeric types are allowed in range [E0029]
/home/michael/Temp/range.rs:7 "what" ... "well" => (),
^~~~~~~~~~~~~~~~~
/home/michael/Temp/range.rs:7:9: 7:26 help: run `rustc --explain E0029` to see a detailed explanation
/home/michael/Temp/range.rs:7:9: 7:26 note: Start type: &'static str
End type: &'static str
/home/michael/Temp/range.rs:7 "what" ... "well" => (),
^~~~~~~~~~~~~~~~~
/home/michael/Temp/range.rs:8:16: 8:25 error: only char and numeric types are allowed in range [E0029]
/home/michael/Temp/range.rs:8 10 ... "what" => ()
^~~~~~~~~
/home/michael/Temp/range.rs:8:16: 8:25 help: run `rustc --explain E0029` to see a detailed explanation
/home/michael/Temp/range.rs:8:16: 8:25 note: Start type: _
End type: &'static str
/home/michael/Temp/range.rs:8 10 ... "what" => ()
^~~~~~~~~
error: aborting due to 5 previous errors
```
I think this is already tonnes better, but the `Start type/End type` stuff could be neater. I don't think there's really any need to start a `note:` block but I wanted to get some feedback on this. I'd also appreciate advice on how to print the integer types as something other than `_`.
This was always a weird feature, and isn't being used in the compiler.
Static assertions should be done better than this.
This implements RFC #1096.
Fixes#13951Fixes#23008Fixes#6676
This is behind a feature gate, but that's still a
[breaking-change]
The E0397 explanation, as I've written it, isn't really an explanation, but I'm not sure what to put here. I will happily take suggestions.
Partially addresses https://github.com/rust-lang/rust/issues/25851
Currently, for `use` declarations with multiple paths, only the `use` item itself is saved in the AST map, not the individual path nodes. This can lead to a problem when a span of a specific path node is needed.
For example, #24818 caused an ICE because of this, in `ImportResolver::check_for_conflicting_import()`.
Fixes#25763.
Changes:
- adds explanations for E0185, E0186, E0202, E0326
- fixes the explanation for E0053. The previous description was too narrow; there are other error cases.
- changes the error message for E0202 to be specific for associated types, since it seems inherent associated constants are implemented.
Part of #24407
Closes#25046 (by rejecting the code that causes the ICE) and #24946. I haven't been able to deal with the array size or recursion issues yet for associated consts, though my hope was that the change I made for range match patterns might help with array sizes, too.
This PR is pretty much orthogonal to #25065.
Currently, for `use` declarations with multiple paths, only the `use`
item itself is saved in the AST map, not the individual path nodes. This
can lead to a problem when a span of a specific path node is needed.
For example, #24818 caused an ICE because of this, in
`ImportResolver::check_for_conflicting_import()`.
Fixes#25763.
- add feature gate
- add basic tests
- adjust parser to eliminate conflict between `const fn` and associated
constants
- allow `const fn` in traits/trait-impls, but forbid later in type check
- correct some merge conflicts
I think I didn't run tests properly - my second call to
select_all_obligations_or_error has made 3 tests fail. However, this is
just an error message change - integer fallback never worked with casts.
This should hopefully fix all cast-related ICEs once and for all.
I managed to make diagnostics hate me and give me spurious "decoder error"
- removing $build/tmp/extended-errors seems to fix it.
Constants with values that depend on generic parameters or `Self` cause
ICEs in `check_const`, and are not yet accepted via RFC, so we need to
throw a proper error in these cases.
This allows compiling entire crates from memory or preprocessing source files before they are tokenized.
Minor API refactoring included, which is a [breaking-change] for libsyntax users:
* `ParseSess::{next_node_id, reserve_node_ids}` moved to rustc's `Session`
* `new_parse_sess` -> `ParseSess::new`
* `new_parse_sess_special_handler` -> `ParseSess::with_span_handler`
* `mk_span_handler` -> `SpanHandler::new`
* `default_handler` -> `Handler::new`
* `mk_handler` -> `Handler::with_emitter`
* `string_to_filemap(sess source, path)` -> `sess.codemap().new_filemap(path, source)`
