bors [Tue, 7 Jan 2020 08:11:07 +0000 (08:11 +0000)]
Auto merge of #67961 - ehuss:update-cargo, r=alexcrichton
Update cargo
9 commits in 86134e7666a088682f20b76278c3ee096a315218..6e1ca924a67dd1ac89c33f294ef26b5c43b89168
2019-12-23 16:08:07 +0000 to 2020-01-06 19:11:37 +0000
- Fix dynamic linking for Windows UWP MSVC targets (rust-lang/cargo#7758)
- Fix CARGO_TARGET_triple_LINKER environment variable. (rust-lang/cargo#7763)
- Remove metadata dep_kinds duplicates. (rust-lang/cargo#7756)
- Check for a source defined multiple times. (rust-lang/cargo#7751)
- Fix typo. (rust-lang/cargo#7735)
- Fix config env vars that are prefix of another with underscore. (rust-lang/cargo#7748)
- Add test for `cargo pkgid` (rust-lang/cargo#7741)
- Add a note to the error message for using --feature / --no-default-features in a virtual workspace (rust-lang/cargo#7742)
- Fix debug message. (rust-lang/cargo#7749)
4 commits in d8dfe1b005c03584cd7adc4bfb72b005e7e84744..e1157538e86d83df0cf95d5e33bd943f80d0248f
2019-12-14 21:04:58 +0100 to 2019-12-22 13:13:14 +0100
- Fix typo in macros-by-example.md (rust-lang-nursery/reference#733)
- Remove `extern` from exception list (rust-lang-nursery/reference#732)
- Added clearification that closures are refered to lambdas (rust-lang-nursery/reference#731)
- abi.md: clarify #[used] and linking (rust-lang-nursery/reference#712)
Yuki Okushi [Tue, 7 Jan 2020 04:46:08 +0000 (13:46 +0900)]
Rollup merge of #67909 - varkor:obsolete-const-print, r=davidtwco
Fix ICE in const pretty printing and resolve FIXME
Consts now have a `fmt::Display` impl, so we can just use that to pretty-print.
This resolves an ICE in https://github.com/rust-lang/rust/issues/61936, though it hits more ICEs afterwards. I couldn't find a test case that was resolved by this that didn't hit errors later on.
Yuki Okushi [Tue, 7 Jan 2020 04:46:04 +0000 (13:46 +0900)]
Rollup merge of #67880 - lbonn:fix/multi-substs, r=petrochenkov
Handle multiple error fix suggestions carefuly
The existing code seems to assume that substitutions spans are disjoint,
which is not always the case.
In the example:
pub trait AAAA {}
pub trait B {}
pub trait C {}
pub type T<P: AAAA + B + C> = P;
, we get three substituions starting from ':' and ending respectively at
the end of each trait token.
With the former offset calculation, this would cause `underline_start` to
eventually become negative before being converted to `usize`...
The new version may report erroneous results for non perfectly overlapping
substitutions but I don't know if such examples exist. Alternatively, we
could detect these cases and trim out overlapping substitutions.
Yuki Okushi [Tue, 7 Jan 2020 04:46:02 +0000 (13:46 +0900)]
Rollup merge of #67877 - dtolnay:const-_, r=nagisa
Omit underscore constants from rustdoc
Underscore constants from https://github.com/rust-lang/rfcs/pull/2526 / https://github.com/rust-lang/rust/issues/54912 do not correspond to a nameable item and so are never useful in documentation.
<br>
Yuki Okushi [Tue, 7 Jan 2020 04:45:58 +0000 (13:45 +0900)]
Rollup merge of #67566 - Mark-Simulacrum:thread-id-u64, r=alexcrichton
Add an unstable conversion from thread ID to u64
We see multiple cases inside rustc and ecosystem code where ThreadId is
transmuted to u64, exploiting the underlying detail. This is suboptimal
(can break unexpectedly if we change things in std).
It is unlikely that ThreadId will ever need to be larger than u64 --
creating even 2^32 threads over the course of a program is quite hard,
2^64 is even harder. As such, we do not choose to return a larger sized
type (e.g. u128). If we choose to shrink ThreadId in the future, or
otherwise change its internals, it is likely that a mapping to u64 will
still be applicable (though may become more complex).
I will file a tracking issue as soon as this is loosely approved.
Mark Rousskov [Mon, 23 Dec 2019 17:54:54 +0000 (12:54 -0500)]
Add an unstable conversion from thread ID to u64
We see multiple cases inside rustc and ecosystem code where ThreadId is
transmuted to u64, exploiting the underlying detail. This is suboptimal
(can break unexpectedly if we change things in std).
It is unlikely that ThreadId will ever need to be larger than u64 --
creating even 2^32 threads over the course of a program is quite hard,
2^64 is even harder. As such, we do not choose to return a larger sized
type (e.g. u128). If we choose to shrink ThreadId in the future, or
otherwise change its internals, it is likely that a mapping to u64 will
still be applicable (though may become more complex).
Dylan DPC [Mon, 6 Jan 2020 06:30:16 +0000 (12:00 +0530)]
Rollup merge of #67800 - Aaron1011:fix/mir-generic-instance, r=oli-obk
Fix ICE involving calling `Instance.ty` during const evaluation
Fixes #67639
`Instance.ty` assumes that we are in a fully monomorphic context (e.g.
codegen), and can therefore use an empty `ParamEnv` when performing
normalization. Howver, the MIR constant evaluator code ends up calling
`Instance.ty` as a result of us attemptign to 'speculatively'
const-evaluate generic functions during const propagation.
As a result,
we may end up with projections involving type parameters
(e.g. <T as MyTrait>::Bar>) in the type we are trying to normalize.
Normalization expects us to have proper predicates in the `ParamEnv` for
such projections, and will ICE if we don't.
This commit adds a new method `Instance.ty_env`, which takes a
`ParamEnv` for use during normalization. The MIR const-evaluator code is
changed to use this method, passing in the proper `ParamEnv` for the
context at hand.
Aaron Hill [Thu, 2 Jan 2020 05:42:31 +0000 (00:42 -0500)]
Fix ICE involving calling `Instance.ty` during const evaluation
Fixes #67639
`Instance.ty` assumes that we are in a fully monomorphic context (e.g.
codegen), and can therefore use an empty `ParamEnv` when performing
normalization. Howver, the MIR constant evaluator code ends up calling
`Instance.ty` as a result of us attemptign to 'speculatively'
const-evaluate generic functions during const propagation.
As a result,
we may end up with projections involving type parameters
(e.g. <T as MyTrait>::Bar>) in the type we are trying to normalize.
Normalization expects us to have proper predicates in the `ParamEnv` for
such projections, and will ICE if we don't.
This commit adds a new method `Instance.ty_env`, which takes a
`ParamEnv` for use during normalization. The MIR const-evaluator code is
changed to use this method, passing in the proper `ParamEnv` for the
context at hand.
Laurent Bonnans [Sat, 4 Jan 2020 23:58:41 +0000 (00:58 +0100)]
Handle multiple error fix suggestions carefuly
The existing code seems to assume that substitutions spans are disjoint,
which is not always the case.
In the example:
pub trait AAAA {}
pub trait B {}
pub trait C {}
pub type T<P: AAAA + B + C> = P;
, we get three substituions starting from ':' and ending respectively at
the end of each trait token.
With the former offset calculation, this would cause `underline_start` to
eventually become negative before being converted to `usize`...
The new version may report erroneous results for non perfectly overlapping
substitutions but I don't know if such examples exist. Alternatively, we
could detect these cases and trim out overlapping substitutions.
bors [Sun, 5 Jan 2020 01:18:57 +0000 (01:18 +0000)]
Auto merge of #67808 - Marwes:projection_normalization_recurse, r=nikomatsakis
perf: Don't recurse into types that do not need normalizing
A bit speculative at this stage but profiling shows that type folding
takes up a substantial amount of time during normalization which may
indicate that many types may be folded despite there being nothing to
normalize
bors [Sat, 4 Jan 2020 21:50:12 +0000 (21:50 +0000)]
Auto merge of #67803 - Centril:librustc_hir, r=Zoxc
Extract `rustc_hir` out of `rustc`
The new crate contains:
```rust
pub mod def;
pub mod def_id;
mod hir;
pub mod hir_id;
pub mod itemlikevisit;
pub mod pat_util;
pub mod print;
mod stable_hash_impls;
pub use hir::*;
pub use hir_id::*;
pub use stable_hash_impls::HashStableContext;
```
Remains to be done in follow-up PRs:
- Move `rustc::hir::map` into `rustc_hir_map` -- this has to be a separate crate due to the `dep_graph` (blocked on https://github.com/rust-lang/rust/pull/67761).
- Move references to `rustc::hir` to `rustc_hir` where possible.
bors [Sat, 4 Jan 2020 18:39:14 +0000 (18:39 +0000)]
Auto merge of #67874 - Dylan-DPC:rollup-xy6bkoe, r=Dylan-DPC
Rollup of 4 pull requests
Successful merges:
- #67137 (libstd uses `core::panic::Location` where possible.)
- #67709 (Introduce an option for disabling deduplication of diagnostics)
- #67775 (Make "use $crate" a hard error)
- #67812 (Tweak and extend internal BTreeMap documentation, including debug asserts.)
Dylan DPC [Sat, 4 Jan 2020 18:22:48 +0000 (23:52 +0530)]
Rollup merge of #67709 - petrochenkov:nodedup2, r=Centril
Introduce an option for disabling deduplication of diagnostics
With the intent of using it in UI tests (https://github.com/rust-lang/rust/pull/67122).
The option is boolean (`-Z deduplicate-diagnostics=yes/no`) and can be specified multiple times with later values overriding earlier values (`-Z deduplicate-diagnostics=no -Z deduplicate-diagnostics=yes` == `-Z deduplicate-diagnostics=yes`), so it can be set in a hierarchical way, e.g. UI testing infra may disable the deduplication by default with specific tests being able to enable it back.
projects / rust.git / log