bors [Mon, 3 Jun 2019 22:05:55 +0000 (22:05 +0000)]
Auto merge of #59148 - lcnr:unchecked_maths, r=eddyb
add support for unchecked math
add compiler support for
```rust
/// Returns the result of an unchecked addition, resulting in
/// undefined behavior when `x + y > T::max_value()` or `x + y < T::min_value()`.
pub fn unchecked_add<T>(x: T, y: T) -> T;
/// Returns the result of an unchecked substraction, resulting in
/// undefined behavior when `x - y > T::max_value()` or `x - y < T::min_value()`.
pub fn unchecked_sub<T>(x: T, y: T) -> T;
/// Returns the result of an unchecked multiplication, resulting in
/// undefined behavior when `x * y > T::max_value()` or `x * y < T::min_value()`.
pub fn unchecked_mul<T>(x: T, y: T) -> T;
```
bors [Mon, 3 Jun 2019 08:28:27 +0000 (08:28 +0000)]
Auto merge of #61062 - mark-i-m:mono-mv, r=eddyb,oli-obk
Remove _all_ codegen dependencies on `rustc_mir` :tada:
~This code is pretty self-contained. It has no references to the rest of `rustc_mir`. Moving it to its own crate means that almost all of the references from `rustc_codegen_*` to `rustc_mir` are instead moved to `rustc_monomorphize`, which should help improve compile times for the compiler a bit...~
With the help of eddyb and oli-obk, all of the dependencies of `librustc_codegen_*` on `librustc_mir` have been removed:
- dependencies on `rustc_mir::monomorphize` were moved to `rustc::mir::mono`
- `rustc_mir::const_eval::const_field` is made into a query.
- `rustc_mir::interpret::type_name` is made into a query.
This should help reduce compile time when working on `rustc_mir` :clock1:
bors [Mon, 3 Jun 2019 02:45:35 +0000 (02:45 +0000)]
Auto merge of #61361 - estebank:infer-type, r=varkor
Add more detail to type inference error
When encountering code where type inference fails, add more actionable
information:
```
fn main() {
let foo = Vec::new();
}
```
```
error[E0282]: type annotations needed in `std::vec::Vec<T>`
--> $DIR/vector-no-ann.rs:2:16
|
LL | let foo = Vec::new();
| --- ^^^^^^^^ cannot infer type for `T` in `std::vec::Vec<T>`
| |
| consider giving `foo` a type
```
bors [Mon, 3 Jun 2019 00:02:34 +0000 (00:02 +0000)]
Auto merge of #61008 - GuillaumeGomez:fix-rustdoc-code-highlighting, r=Manishearth
Fix lines highlighting in rustdoc source view
Fixes #60948.
This PR fixes how we handle the lines highlighting from the URL (so in "/doc/src/alloc/string.rs.html#285-283", the "285-283" part). We got a hard limit on 50000, for some unknown and lost reasons which was used in case only one line is selected.
bors [Sun, 2 Jun 2019 14:42:11 +0000 (14:42 +0000)]
Auto merge of #61460 - Centril:rollup-8txhjx4, r=Centril
Rollup of 6 pull requests
Successful merges:
- #61380 (Fix some issues with `unwrap_usize` instead of `assert_usize`)
- #61423 (codegen: change `$6d$` to `$u6d$`)
- #61438 (Point at individual type args on arg count mismatch)
- #61441 (Tweak wording when encountering `fn` call in pattern)
- #61451 (Fix missing semicolon in doc)
- #61458 (Fix typo in AsRef doc)
Rollup merge of #61438 - estebank:generics-span, r=varkor
Point at individual type args on arg count mismatch
- Point at individual type arguments on arg count mismatch
- Make generics always have a valid span, even when there are no args
- Explain that `impl Trait` introduces an implicit type argument
Rollup merge of #61423 - davidtwco:correct-symbol-mangling, r=eddyb
codegen: change `$6d$` to `$u6d$`
This changes a mistake introduced in #61195 where the mangling
workaround used was incorrect, resolving [this comment](https://github.com/rust-lang/rust/pull/61195#discussion_r289597707) from @eddyb.
bors [Sun, 2 Jun 2019 11:46:13 +0000 (11:46 +0000)]
Auto merge of #61276 - eddyb:kill-res-upvar, r=petrochenkov
rustc: remove Res::Upvar.
By keeping track of the current "`body_owner`" (the `DefId` of the current fn/closure/const/etc.) in several passes, `Res::Upvar` and `hir::Upvar` don't need to contain contextual information about the closure.
By leveraging [`indexmap`](https://docs.rs/indexmap), the list of upvars for a given closure can now also be queried, to check whether a local variable is a closure capture, and so `Res::Upvar` can be merged with `Res::Local`.
And finally, the `tcx.upvars(...)` query now collects upvars from HIR, without relying on `rustc_resolve`.
bors [Sun, 2 Jun 2019 04:10:25 +0000 (04:10 +0000)]
Auto merge of #61384 - varkor:fmin-fmax-llvm-opt, r=alexcrichton
Update LLVM to include fmin/fmax optimisations
This will enable us to test if the optimisation issues mentioned in https://github.com/rust-lang/rust/issues/18384 really are fixed. Unfortunately, using the intrinsics immediately is problematic due to the libcore/libstd split (see https://github.com/rust-lang/rust/issues/50145).
bors [Sat, 1 Jun 2019 16:06:11 +0000 (16:06 +0000)]
Auto merge of #61350 - RalfJung:alloc, r=oli-obk
light refactoring of global AllocMap
* rename AllocKind -> GlobalAlloc. This stores the allocation itself, not just its kind.
* rename the methods that allocate stuff to have consistent names.
Rollup merge of #61263 - GuillaumeGomez:valid-html, r=Manishearth
Don't generate div inside header (h4/h3/h...) elements
Fixes #60865.
According to the HTML spec, we're not supposed to put `div` elements inside heading elements (h4/h3/h...). It doesn't change the display as far as I could tell.
bors [Sat, 1 Jun 2019 03:46:13 +0000 (03:46 +0000)]
Auto merge of #60145 - little-dude:ip2, r=alexcrichton
std::net: Ipv4Addr and Ipv6Addr improvements
Picking this up again from my previous PR: https://github.com/rust-lang/rust/pull/56050
Related to: https://github.com/rust-lang/rust/issues/27709 Fixes: https://github.com/rust-lang/rust/issues/57558
- add `add Ipv4Addr::is_reserved()`
- [X] implementation
- [X] tests
- add `Ipv6Addr::is_unicast_link_local_strict()` and update `Ipv6Addr::is_unicast_link_local()` documentation
- [X] implementation
- [X] test
- add `Ipv4Addr::is_benchmarking()`
- [X] implementation
- [X] test
- add `Ipv4Addr::is_ietf_protocol_assignment()`
- [X] implementation
- [X] test
- add `Ipv4Addr::is_shared()`
- [X] implementation
- [x] test
- fix `Ipv4Addr:is_global()`
- [X] implementation
- [x] test
- [X] refactor the tests for IP properties. This makes the tests more verbose, but using macros have two advantages:
- it will now be easier to add tests for all the new methods
- we get clear error messages when a test is failing. For instance:
## Should `Ipv4Addr::is_global()` return `true` or `false` for reserved addresses?
Reserved addresses are addresses that are matched by `Ipv4Addr::is_reserved()`.
@the8472 [pointed out](https://github.com/rust-lang/rust/pull/60145#issuecomment-485458319) that [RFC 4291](https://tools.ietf.org/html/rfc4291#section-2.4) says IPv6 reserved addresses should be considered global:
```
Future specifications may redefine one or more sub-ranges of the
Global Unicast space for other purposes, but unless and until that
happens, implementations must treat all addresses that do not start
with any of the above-listed prefixes as Global Unicast addresses.
```
We could extrapolate that this should also be the case for IPv4. However, it seems that [IANA considers them non global](https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml) (see [my comment](https://github.com/rust-lang/rust/pull/60145#issuecomment-485713270))
### Final decision
There seems to be a consensus that reserved addresses have a different meaning for IPv4 and IPv6 ([comment1](https://github.com/rust-lang/rust/pull/60145#issuecomment-485963789) [comment2](https://github.com/rust-lang/rust/pull/60145#issuecomment-485944582), so we can consider that RFC4291 does not apply to IPv4, and that reserved IPv4 addresses are _not_ global.
## Should `Ipv6Addr::is_unicast_site_local()` exist?
@pusateri [noted](https://github.com/rust-lang/rust/pull/60145#issuecomment-485507515) that site-local addresses have been deprecated for a while by [RFC 3879](https://tools.ietf.org/html/rfc3879) and new implementations _must not_ support them. However, since this method is stable, removing does not seem possible. This kind of situation is covered by the RFC which stated that existing implementation _may_ continue supporting site-local addresses.
### Final decision
Let's keep this method. It is stable already, and the RFC explicitly states that existing implementation may remain.
---------
Note: I'll be AFK from April 27th to May 11th. Anyone should feel free to pick this up if the PR hasn't been merged by then. Sorry for dragging that for so long already.
Esteban Küber [Thu, 30 May 2019 22:33:13 +0000 (15:33 -0700)]
On type inference errors use the type argument name when possible
```
error[E0282]: type annotations needed in `std::result::Result<i32, E>`
--> file7.rs:3:13
|
3 | let b = Ok(4);
| - ^^ cannot infer type for `E` in `std::result::Result<i32, E>`
| |
| consider giving `b` a type`
```
Esteban Küber [Thu, 30 May 2019 17:19:58 +0000 (10:19 -0700)]
Add more detail to type inference error
When encountering code where type inference fails, add more actionable
information:
```
fn main() {
let foo = Vec::new();
}
```
```
error[E0282]: type annotations needed for `std::vec::Vec<_>`
--> $DIR/vector-no-ann.rs:2:16
|
LL | let foo = Vec::new();
| --- ^^^^^^^^ cannot infer type for `T`
| |
| consider giving `foo` the type `std::vec::Vec<_>` with the type parameter `T` specified
```
We still need to modify type printing to optionally accept a
`TypeVariableTable` in order to properly print `std::vec::Vec<T>`.
projects / rust.git / log