Issue: https://github.com/rust-lang/rust/issues/25969
Compare the span on the stable branch (correct) with the span on the nightly branch (incorrect) for the following example: http://is.gd/lTAo9c. This pull request fixes the regression.
@Manishearth has been kind enough to pitch some ideas for a regression test, mainly revolving around testing the span in compile-fail test, but this has proven unsuccessful. Other suggestions/ ideas would be much appreciated!
The API documentation is not explicit enough that because `try!` returns
`Err` early for you, you can only use it in functions that return
`Result`. The book mentions this, but if you come across `try!` outside
of the book and look it up in the docs, this restriction on the return
type of the function is not particularly clear.
I seriously had this epiphany a few days ago after working with Rust for MONTHS, and after seeing [a friend have to come to the same realization](http://joelmccracken.github.io/entries/a-simple-web-app-in-rust-pt-2a/), I'd like to save more people from this confusion :) 💖
Fix the dropck doc formatting to avoid hitting four-space indent.
This was causing `rustdoc` to interpret the part starting with `(A.) ...` as a code block based on its four-space indentation, which then was treated by `rustdoc` as a *Rust* code snippet, and thus was attempting (and failing) to parse my english as Rust code. Thus causing the compiler-docs build to fail.
Independently, we should probably change `rustdoc` to not interpret four-space indents as code that needs to be tested; it seems too perilous to me at least.
(But the formatting here needed to be changed either way.)
cc Issue #25699.
My main sources of information are [RFC401](https://github.com/rust-lang/rfcs/blob/master/text/0401-coercions.md), the rust IRC channel, and a bunch of experiments to figure out what `rustc` currently supports.
Note that the RFC calls for some coercion behaviour that is not implemented yet (see #18469).
The documentation in this PR mostly covers current behaviour of rust and doesn't document the future behaviour. I haven't written about receiver expression coercion.
I would be happy to rewrite/adapt the PR according to feedback.
r? @steveklabnik
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 `_`.
On MSVC there are two ways that the CRT can be linked, either statically or
dynamically. Each object file produced by the compiler is compiled against
msvcrt (a dll) or libcmt (a static library). When the linker is dealing with
more than one object file, it requires that all object files link to the same
CRT, or else the linker will spit out some errors.
For now, compile code with `-MD` as it seems to appear more often in C libraries
so we'll stick with the same trend.
Hack the move_val_init intrinsic to trans directly into the destination address.
This is to remove an intermediate (and unnecessary) alloca on the stack that one otherwise suffers when using this intrinsic.
This is part of the `box` protocol work; in particular, this is meant to address the `ptr::write` codegen issues alluded to at this comment:
https://github.com/rust-lang/rust/pull/22086#issuecomment-96168675
cc #22181
This was always a weird feature, and isn't being used in the compiler.
Static assertions should be done better than this.
Fixes#13951Fixes#23008Fixes#6676
This is behind a feature gate, but that's still a
[breaking-change]
(It's not entirely clear to me that this should or shouldn't have an RFC, but if it does, I'm fine blocking on such a thing.)
The API documentation is not explicit enough that because `try!` returns
`Err` early for you, you can only use it in functions that return
`Result`. The book mentions this, but if you come across `try!` outside
of the book and look it up in the docs, this restriction on the return
type of the function is not particularly clear.
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]
This was causing `rustdoc` to interpret the part starting with
`(A.) ...` as a code block based on its four-space indentation,
which then was treated by `rustdoc` as a *Rust* code snippet,
and thus was attempting (and failing) to parse my english as
Rust code. Thus causing the compiler-docs build to fail.
Independently, we should probably change `rustdoc` to not interpret
four-space indents as code that needs to be tested; it seems too
perilous to me at least.
(But the formatting here needed to be changed either way.)
cc Issue #25699.
These are implemented in asm, they're just not inlined.
Open questions are:
* Should I just inline them? They're.. big, but it seems as though this needs violates the #[inline(always)] gaurantees the others make.
* Does something (llvm?) provide these as intrinsics? The structure of this code suggests that we could be hoisting off something else, instead of flagrantly ignoring it like we do for power and mips.
Bug fixes for configure on FreeBSD:
- Don't ban using gcc; newer versions can be installed and other checks should enforce its suitability.
- Don't force Rust to link itself with /usr/local/lib{,gcc4[46]}, which causes builds to fail if Rust is already installed. I've not been able to find an use case where this is actually necessary.
The compiler already has special support for fixing up verbatim paths with disks
on Windows to something that can be correctly passed down to gcc, and this
commit adds support for verbatim UNC paths as well.
Closes#25505
