bors [Mon, 28 May 2018 22:28:43 +0000 (22:28 +0000)]
Auto merge of #50465 - clarcharr:wrapping, r=KodrAus
Add missing Wrapping methods, use doc_comment!
Re-opened version of #49393 . Finishing touches for #32463.
Note that this adds `Shl` and `Shr` implementations for `Wrapping<i128>` and `Wrapping<u128>`, which were previously missed. This is technically insta-stable, but I don't know why this would be a problem.
bors [Mon, 28 May 2018 19:16:27 +0000 (19:16 +0000)]
Auto merge of #50929 - zackmdavis:hiridification_initiative, r=michaelwoerister
operate on `HirId` instead of `NodeId` in `hir::Pat::each_binding`, and consequences of that
See #50928 for motivation.
Questions—
* Is #50928 actually a good idea as a plan of record, or is there some reason to keep `NodeId`s?
* Are the uses of `find_node_for_hir_id` in this initial submission OK (see the FIXME comments)?
* Can we bikeshed a better method names `struct_span_lint_hir` _&c._? (Coined in analogy to the `struct_span_lint_node` and `NodeId`, but it feels kind of semantically clunky.)
bors [Mon, 28 May 2018 16:54:44 +0000 (16:54 +0000)]
Auto merge of #50521 - gnzlbg:simd_float, r=alexcrichton
Add simd math intrinsics and gather/scatter
This PR adds simd math intrinsics for floating-point vectors (sqrt, sin, cos, pow, exp, log, fma, abs, etc.) and the generic simd gather/scatter intrinsics.
Zack M. Davis [Sun, 27 May 2018 00:30:26 +0000 (17:30 -0700)]
scrap `find_node_for_hir_id` in favor of `hir_to_node_id`
Michael Woerister pointed out that `hir_to_node_id` (introduced in
August 2017's 28ddd7a4e) supersedes the functionality of
`find_node_for_hir_id` (just a hash lookup compared to that linear
search).
Zack M. Davis [Mon, 21 May 2018 03:19:34 +0000 (20:19 -0700)]
operate on `HirId` in `hir::Pat::each_binding`, and consequences of that
Changing the `each_binding` utility method to take the `HirId` of a
binding pattern rather than its `NodeId` seems like a modest first step
in support of the `HirId`ification initiative #50928. (The inspiration
for choosing this in particular came from the present author's previous
work on diagnostics issued during liveness analysis, which is the most
greatly affected module in this change.)
bors [Mon, 28 May 2018 10:11:26 +0000 (10:11 +0000)]
Auto merge of #50724 - zackmdavis:applicability_rush, r=Manishearth
add suggestion applicabilities to librustc and libsyntax
A down payment on #50723. Interested in feedback on whether my `MaybeIncorrect` vs. `MachineApplicable` judgement calls are well-calibrated (and that we have a consensus on what this means).
bors [Sun, 27 May 2018 22:28:11 +0000 (22:28 +0000)]
Auto merge of #48309 - mark-i-m:anon_param_lint, r=nikomatsakis
Make anon params lint warn-by-default
This is intended as a followup on anonymous parameters deprecation.
Cross-posting from #41686:
> After having read a bit more of the discussion that I can find, I propose a more aggressive deprecation strategy:
> - We make the lint warn-by-default as soon as possible
> - We make anon parameters a hard error at the epoch boundary
bors [Sun, 27 May 2018 00:54:12 +0000 (00:54 +0000)]
Auto merge of #51066 - est31:master, r=sfackler
Point to the current box syntax tracking issue
The issue was used for both box syntax as well as placement new.
It got closed due to placement new being unapproved.
So a new one got created for box syntax, yet neither
the unstable book nor feature_gate.rs got updated.
We are doing this now.
bors [Sat, 26 May 2018 19:05:39 +0000 (19:05 +0000)]
Auto merge of #51094 - Mark-Simulacrum:rollup, r=Mark-Simulacrum
Rollup of 3 pull requests
Successful merges:
- #51049 (Fix behaviour of divergence in while loop conditions)
- #51057 (make ui tests robust with respect to NLL)
- #51092 ([master] Release notes for 1.26.1)
est31 [Fri, 25 May 2018 20:37:25 +0000 (22:37 +0200)]
Point to the current box syntax tracking issue
The issue was used for both box syntax as well as placement new.
It got closed due to placement new being unapproved.
So a new one got created for box syntax, yet neither
the unstable book nor feature_gate.rs got updated.
We are doing this now.
Mark Simulacrum [Sat, 26 May 2018 17:22:54 +0000 (11:22 -0600)]
Rollup merge of #51057 - pnkfelix:issue-51025-make-ui-tests-robust-wrt-nll, r=nikomatsakis
make ui tests robust with respect to NLL
This PR revises the `ui` tests that I could quickly identify that:
1. previously had successful compilations under non-lexical lifetimes (NLL) because they assumed lexical lifetimes, but
2. such assumption of lexical lifetimes was actually not necessarily part of the spirit of the original issue/bug we want to witness.
In many cases, this is simply a matter of adding a use of a borrow so that it gets extended long enough to observe a conflict.
(In some cases the revision was more subtle, such as adding a destructor, or revising the order of declaration of some variables.)
----
With these test revisions in place, I subsequently updated the expected stderr output under the NLL compiletest mode. So now we should get even more testing of NLL than we were before.
bors [Sat, 26 May 2018 12:03:28 +0000 (12:03 +0000)]
Auto merge of #51082 - kennytm:rollup, r=kennytm
Rollup of 11 pull requests
Successful merges:
- #50987 (Underline multiple suggested replacements in the same line)
- #51014 (Add documentation about env! second argument)
- #51034 (Remove unused lowering field and method)
- #51047 (Use AllFacts from polonius-engine)
- #51048 (Add more missing examples for Formatter)
- #51056 (Mention and use `Once::new` instead of `ONCE_INIT`)
- #51059 (What does an expression look like, that consists only of special characters?)
- #51065 (Update nomicon link in transmute docs)
- #51067 (Add inner links in documentation)
- #51070 (Fail typecheck if we encounter a bogus break)
- #51073 (Rename TokenStream::empty to TokenStream::new)
kennytm [Sat, 26 May 2018 11:32:32 +0000 (19:32 +0800)]
Rollup merge of #51070 - est31:fix_break_const_ice, r=estebank
Fail typecheck if we encounter a bogus break
Lone breaks outside of loops create errors in the
loop check pass but as they are not fatal,
compilation continues.
MIR building code assumes all HIR break statements
to point to valid locations and fires ICEs if this
assumption is violated. In normal compilation,
this causes no issues, as code apparently prevents
MIR from being built if errors are present.
However, before that, typecheck runs and with it
MIR const eval. Here we operate differently
from normal compilation: it doesn't check for any
errors except for type checker ones and then
directly builds the MIR.
This constellation causes an ICE-on-error if
bogus break statements are being put into array
length expressions.
This commit fixes this ICE by letting typecheck
fail if bogus break statements are encountered.
This way, MIR const eval fails cleanly with a
type check error.
kennytm [Sat, 26 May 2018 11:32:30 +0000 (19:32 +0800)]
Rollup merge of #51067 - mcarton:patch-1, r=steveklabnik
Add inner links in documentation
From [this SO question](https://stackoverflow.com/q/50518757/2733851) it looks like this page isn't really clear.
I personally do think this page is quite clear, the only think I could think of was adding some references.
kennytm [Sat, 26 May 2018 11:32:21 +0000 (19:32 +0800)]
Rollup merge of #51034 - oli-obk:lowering, r=pnkfelix
Remove unused lowering field and method
r? @nikomatsakis
So while trying to understand lowering better, I found out that there's something related to creating definitions. Analyzing that further, I realized that it is entirely dead code.
The `parent_def` field was only ever used for setting and resetting the field itself. The field was never read anywhere else and thus its value was entirely unused.
Maybe the `unused_field` lint should detect when the only use of a field is the field being read without using the read value other than writing back to the field?
The diff is best viewed without whitespace changes getting in the way: https://github.com/rust-lang/rust/pull/51034/files?w=1
bors [Sat, 26 May 2018 09:59:43 +0000 (09:59 +0000)]
Auto merge of #51041 - alexcrichton:better-unwind, r=nikomatsakis
std: Ensure OOM is classified as `nounwind`
OOM can't unwind today, and historically it's been optimized as if it can't
unwind. This accidentally regressed with recent changes to the OOM handler, so
this commit adds in a codegen test to assert that everything gets optimized away
after the OOM function is approrpiately classified as nounwind
bors [Sat, 26 May 2018 07:33:06 +0000 (07:33 +0000)]
Auto merge of #50364 - LukasKalbertodt:improve-duration-debug-impl, r=KodrAus
Improve `Debug` impl of `time::Duration`
Hi there!
For a long time now, I was getting annoyed by the derived `Debug` impl of `Duration`. Usually, I use `Duration` to either do quick'n'dirty benchmarking or measuring the time of some operation in general. The output of the derived Debug impl is hard to parse for humans: is { secs: 0, nanos: 968360102 } or { secs: 0, nanos 98507324 } longer?
So after running into the annoyance several times (sometimes building my own function to print the Duration properly), I decided to tackle this. Now the output looks like this:
Note that I implemented the formatting manually and didn't use floats. No information is "lost" when printing. So `Duration::new(123_456_789_000, 900_000_001)` prints as `123456789000.900000001s`.
~~This is not yet finished~~, but I wanted to open the PR now already in order to get some feedback (maybe everyone likes the derived impl).
### Still ToDo:
- [x] Respect precision ~~and width~~ parameter of the formatter (see [this comment](https://github.com/rust-lang/rust/pull/50364#issuecomment-386107107))
### Alternatives/Decisions
- Should large durations displayed in minutes, hours, days, ...? For now, I decided not to because the current formatting is close the how a `Duration` is stored. From this new `Debug` output, you can still easily see what the values of `secs` and `nanos` are. A formatting like `3h 27m 12s 9ms` might be more appropriate for a `Display` impl?
- Should this rather be a `Display` impl and should `Debug` be derived? Maybe this formatting is too fancy for `Debug`? In my opinion it's not and, as already mentioned, from the current format one can still very easily determine the values for `secs` and `nanos`.
- Whitespace between the number and the unit?
### Notes for reviewers
- ~~The combined diff sucks. Rather review both commits individually.~~
- ~~In the unit test, I am building my own type implementing `fmt::Write` to test the output. Maybe there is already something like that which I can use?~~
- My `Debug` impl block is marked as `#[stable(...)]`... but that's fine since the derived Debug impl was stable already, right?
---
~~Apart from the main change, I moved all `time` unit tests into the `tests` directory. All other `libcore` tests are there, so I guess it was simply an oversight. Prior to this change, the `time` tests weren't run, so I guess this is kind of a bug fix. If my `Debug` impl is rejected, I can of course just send the fix as PR.~~ (this was already merged in #50466)
Zack M. Davis [Sun, 15 Apr 2018 21:30:23 +0000 (14:30 -0700)]
in which we check for confusable Unicodepoints in float literal exponent
The `FatalError.raise()` might seem unmotivated (in most places in
the compiler, `err.emit()` suffices), but it's actually used to
maintain behavior (viz., stop lexing, don't emit potentially spurious
errors looking for the next token after the bad Unicodepoint in the
exponent): the previous revision's `self.err_span_` ultimately calls
`Handler::emit`, which aborts if the `Handler`'s continue_after_error
flag is set, which seems to typically be true during lexing (see
`phase_1_parse_input` and and how `CompileController::basic` has
`continue_parse_after_error: false` in librustc_driver).
Also, let's avoid apostrophes in error messages (the present author
would argue that users expect a reassuringly detached, formal,
above-it-all tone from a Serious tool like a compiler), and use an
RLS-friendly structured suggestion.
est31 [Sat, 26 May 2018 00:48:08 +0000 (02:48 +0200)]
Fail typecheck if we encounter a bogus break
Lone breaks outside of loops create errors in the
loop check pass but as they are not fatal,
compilation continues.
MIR building code assumes all HIR break statements
to point to valid locations and fires ICEs if this
assumption is violated. In normal compilation,
this causes no issues, as code apparently prevents
MIR from being built if errors are present.
However, before that, typecheck runs and with it
MIR const eval. Here we operate differently
from normal compilation: it doesn't check for any
errors except for type checker ones and then
directly builds the MIR.
This constellation causes an ICE-on-error if
bogus break statements are being put into array
length expressions.
This commit fixes this ICE by letting typecheck
fail if bogus break statements are encountered.
This way, MIR const eval fails cleanly with a
type check error.
bors [Fri, 25 May 2018 22:18:27 +0000 (22:18 +0000)]
Auto merge of #51033 - coryshrmn:master, r=dtolnay
stabilize RangeBounds collections_range #30877
The FCP for #30877 closed last month, with the decision to:
1. move from `collections::range::RangeArgument` to `ops::RangeBounds`, and
2. rename `start()` and `end()` to `start_bounds()` and `end_bounds()`.
Simon Sapin already moved it to `ops::RangeBounds` in #49163.
I renamed the functions, and removed the old `collections::range::RangeArgument` alias.
This is my first Rust PR, please let me know if I can improve anything. This passes all tests for me, except the `clippy` tool (which uses `RangeArgument::start()`).
I considered deprecating `start()` and `end()` instead of removing them, but the contribution guidelines indicate we can break `clippy` temporarily. I thought it was best to remove the functions, since we're worried about name collisions with `Range::start` and `end`.
Martin Carton [Fri, 25 May 2018 20:55:33 +0000 (22:55 +0200)]
Add inner links in documentation
From [this SO question](https://stackoverflow.com/q/50518757/2733851) it looks like this page isn't really clear.
I personally do think this page is quite clear, the only think I could think of was adding some references.
projects / rust.git / log