That PR makes error messages worse than before, and we couldn't come up with a way of actually making them better, so revert it for now. Any idea for making this error message better is welcome!
Rollup merge of #63230 - tmandry:disallow-possibly-uninitialized, r=Centril
Make use of possibly uninitialized data [E0381] a hard error
This is one of the behaviors we no longer allow in NLL. Since it can
lead to undefined behavior, I think it's definitely worth making it a
hard error without waiting to turn off migration mode (#58781).
Closes #60450.
My ulterior motive here is making it impossible to leave variables
partially initialized across a yield (see #60889, discussion at #63035), so
tests are included for that.
cc #54987
---
I'm not sure if bypassing the buffer is a good way of doing this. We could also make a `force_errors_buffer` or similar that gets recombined with all the errors as they are emitted. But this is simpler and seems fine to me.
r? @Centril
cc @cramertj @nikomatsakis @pnkfelix @RalfJung
Rollup merge of #63184 - JasonShin:master, r=sfackler
Explaining the reason why validation is performed in to_str of path.rs
I thought it's good to explain the reason for the validation during the conversion between Path/PathBuffer into str, which explains the reason for returning an Option at this point (good for beginners who are reading through the docs).
Rollup merge of #63017 - matklad:no-fatal, r=petrochenkov
Remove special code-path for handing unknown tokens
In `StringReader`, we have a buffer of fatal errors, which is used only in a single case: when we see something which is not a reasonable token at all, like `🦀`. I think a more straightforward thing to do here is to produce an explicit error token in this case, and let the next layer (the parser), deal with it.
However currently this leads to duplicated error messages. What should we do with this? Naively, I would think that emitting (just emitting, not raising) `FatalError` should stop other errors, but looks like this is not the case? We can also probably tweak parser on the case-by-case basis, to avoid emitting "expected" errors if the current token is an `Err`. I personally also fine with cascading errors in this case: it's quite unlikely that you actually type a fully invalid token.
@petrochenkov, which approach should we take to fight cascading errors?
Rollup merge of #61457 - timvermeulen:double_ended_iters, r=scottmcm
Implement DoubleEndedIterator for iter::{StepBy, Peekable, Take}
Now that `DoubleEndedIterator::nth_back` has landed, `StepBy` and `Take` can have an efficient `DoubleEndedIterator` implementation. I don't know if there was any particular reason for `Peekable` not having a `DoubleEndedIterator` implementation, but it's quite trivial and I don't see any drawbacks to having it.
I'm not very happy about the implementation of `Peekable::try_rfold`, but I didn't see another way to only take the value out of `self.peeked` in case `self.iter.try_rfold` didn't exit early.
I only added `Peekable::rfold` (in addition to `try_rfold`) because its `Iterator` implementation has both `fold` and `try_fold` (and for similar reasons I added `Take::try_rfold` but not `Take::rfold`). Do we have any guidelines on whether we want both? If we do want both, maybe we should investigate which iterator adaptors override `try_fold` but not `fold` and add the missing implementations. At the moment I think that it's better to always have iterator adaptors implement both, because some iterators have a simpler `fold` implementation than their `try_fold` implementation.
The tests that I added may not be sufficient because they're all just existing tests where `next`/`nth`/`fold`/`try_fold` are replaced by their DEI counterparts, but I do think all paths are covered. Is there anything in particular that I should probably also test?
Tyler Mandry [Sat, 3 Aug 2019 00:08:16 +0000 (17:08 -0700)]
Make use of possibly uninitialized data a hard error
This is one of the behaviors we no longer allow in NLL. Since it can
lead to undefined behavior, I think it's definitely worth making it a
hard error without waiting to turn off migration mode (#58781).
Closes #60450.
My ulterior motive here is making it impossible to leave variables
partially initialized across a yield (see discussion at #63035), so
tests are included for that.
bors [Mon, 5 Aug 2019 04:36:51 +0000 (04:36 +0000)]
Auto merge of #63248 - petrochenkov:nomarker, r=matthewjasper
Move special treatment of `derive(Copy, PartialEq, Eq)` from expansion infrastructure to elsewhere
As described in https://github.com/rust-lang/rust/pull/62086#issuecomment-515195477.
Reminder:
- `derive(PartialEq, Eq)` makes the type it applied to a "structural match" type, so constants of this type can be used in patterns (and const generics in the future).
- `derive(Copy)` notifies other derives that the type it applied to implements `Copy`, so `derive(Clone)` can generate optimized code and other derives can generate code working with `packed` types and types with `rustc_layout_scalar_valid_range` attributes.
First, the special behavior is now enabled after properly resolving the derives, rather than after textually comparing them with `"Copy"`, `"PartialEq"` and `"Eq"` in `fn add_derived_markers`.
The markers are no longer kept as attributes in AST since derives cannot modify items and previously did it through hacks in the expansion infra.
Instead, the markers are now kept in a "global context" available from all the necessary places, namely - resolver.
For `derive(PartialEq, Eq)` the markers are created by the derive macros themselves and then consumed during HIR lowering to add the `#[structural_match]` attribute in HIR.
This is still a hack, but now it's a hack local to two specific macros rather than affecting the whole expansion infra.
Ideally we should find the way to put `#[structural_match]` on the impls rather than on the original item, and then consume it in `rustc_mir`, then no hacks in expansion and lowering will be required.
(I'll make an issue about this for someone else to solve, after this PR lands.)
The marker for `derive(Copy)` cannot be emitted by the `Copy` macro itself because we need to know it *before* the `Copy` macro is expanded for expanding other macros.
So we have to do it in resolve and block expansion of any derives in a `derive(...)` container until we know for sure whether this container has `Copy` in it or not.
Nasty stuff.
bors [Sun, 4 Aug 2019 11:30:12 +0000 (11:30 +0000)]
Auto merge of #63048 - Aaron1011:feature/rustdoc-reexport-doc, r=GuillaumeGomez
Use doc comments from 'pub use' statements
Split off from #62855
Currently, rustdoc ignores any doc comments found on 'pub use'
statements. As described in issue #58700, this makes it impossible to
properly document procedural macros. Any doc comments must be written on
the procedural macro definition, which must occur in a dedicated
proc-macro crate. This means that any doc comments or doc tests cannot
reference items defined in re-exporting crate, despite the fact that
such items may be required to use the procedural macro.
To solve this issue, this commit allows doc comments to be written on
'pub use' statements. For consistency, this applies to *all* 'pub use'
statements, not just those importing procedural macros.
When inlining documentation, documentation on 'pub use' statements will
be prepended to the documentation of the inlined item. For example,
the following items:
```rust
mod other_mod {
/// Doc comment from definition
pub struct MyStruct;
}
/// Doc comment from 'pub use'
///
pub use other_mod::MyStruct;
```
will caues the documentation for the re-export of 'MyStruct' to be
rendered as:
```
Doc comment from 'pub use'
Doc comment from definition
```
Note the empty line in the 'pub use' doc comments - because doc comments
are concatenated as-is, this ensure that the doc comments on the
definition start on a new line.
bors [Sun, 4 Aug 2019 03:36:10 +0000 (03:36 +0000)]
Auto merge of #63199 - ehuss:fix-rustc-guide-toolstate, r=kennytm
Fix rustc-guide toolstate tracking.
The rustc-guide is still not saving its toolstate. It needs to be done explicitly.
Note: There are some confusing bits here, like without `--no-fail-fast`, it saves the wrong value in `toolstates.json`. Also, "rustbook" is always added as "test-fail". Presumably [this code](https://github.com/rust-lang/rust/blame/63c1f17d950bfefc8f356777f124f304f0575c76/src/bootstrap/tool.rs#L201-L205) assumes everything fails until it passes tests, which is a bit confusing for things that don't run tests.
bors [Sat, 3 Aug 2019 20:11:25 +0000 (20:11 +0000)]
Auto merge of #63059 - Centril:sound-bind-by-move, r=matthewjasper
Make `#![feature(bind_by_move_pattern_guards)]` sound without `#[feature(nll)]`
Implements https://github.com/rust-lang/rust/issues/15287#issuecomment-507054617 making `#![feature(bind_by_move_pattern_guards)]]` sound without also having `#![feature(nll)]`. The logic here is that if we see a `match` guard, we will refuse to downgrade NLL errors to warnings. This is in preparation for hopefully stabilizing the former feature in https://github.com/rust-lang/rust/pull/63118.
As fall out from the implementation we also:
Fixes https://github.com/rust-lang/rust/issues/31287
Fixes https://github.com/rust-lang/rust/issues/27282
bors [Sat, 3 Aug 2019 12:20:42 +0000 (12:20 +0000)]
Auto merge of #63234 - Centril:rollup-h9t731z, r=Centril
Rollup of 5 pull requests
Successful merges:
- #62954 (Fix typo in Delimited::open_tt)
- #63146 (Cleanup syntax::attr)
- #63218 (rustbuild: RISC-V is no longer an experimental LLVM target)
- #63227 (dead_code: Properly inspect fields in struct patterns with type relative paths)
- #63229 (A bit of Miri error cleanup)
Rollup merge of #63218 - lenary:riscv-non-experimental, r=alexcrichton
rustbuild: RISC-V is no longer an experimental LLVM target
This moves RISC-V from the experimental LLVM targets to the
regular LLVM targets. RISC-V was made non-experimental in
https://reviews.llvm.org/rL366399
I have also sorted the list of LLVM targets, and changed the code
around setting llvm_exp_targets (and its default) to match the code
setting llvm_targets (and its default), ensuring future changes to
the defaults, as LLVM targets become stable, affect as few places as
possible.
Given WebAssembly is in `LLVM_ALL_TARGETS` and is therefore built by default (and has been since October 2018), I'm not sure why rust still has it in `experimental-targets`. I'm happy to update this PR to move it into the main list of LLVM targets.
bors [Sat, 3 Aug 2019 08:33:07 +0000 (08:33 +0000)]
Auto merge of #62946 - RalfJung:miri_type_dispatch_first, r=oli-obk
Miri: dispatch first on the type
Based on the fact that Miri now always has intptrcast available, we can change binops and casts to first check the type of the source operand and then decide based on that what to do, instead of considering the value (pointer vs bits) first.
bors [Sat, 3 Aug 2019 02:21:23 +0000 (02:21 +0000)]
Auto merge of #63180 - varkor:trait-alias-impl-trait, r=Centril
Change opaque type syntax from `existential type` to type alias `impl Trait`
This implements a new feature gate `type_alias_impl_trait` (this is slightly different from the originally proposed feature name, but matches what has been used in discussion since), deprecating the old `existential_types` feature.
The syntax for opaque types has been changed. In addition, the "existential" terminology has been replaced with "opaque", as per previous discussion and the RFC.
This makes partial progress towards implementing https://github.com/rust-lang/rust/issues/63063.
bors [Fri, 2 Aug 2019 22:44:53 +0000 (22:44 +0000)]
Auto merge of #63228 - Centril:rollup-x39p5ga, r=Centril
Rollup of 7 pull requests
Successful merges:
- #63107 (Added support for armv7-unknown-linux-gnueabi/musleabi)
- #63121 (On `format!()` arg count mismatch provide extra info)
- #63196 (build_helper: try less confusing method names)
- #63206 (remove unsupported test case)
- #63208 (Round generator sizes to a multiple of their alignment)
- #63212 (Pretty print attributes in `print_arg`)
- #63215 (Clarify semantics of mem::zeroed)
Rollup merge of #63196 - RalfJung:build_helper, r=alexcrichton
build_helper: try less confusing method names
build_helper's `*_silent` methods were likely called that way because they do not print the command being run to stdout. [In the original file this all makes sense](https://github.com/rust-lang/rust/commit/046e6874c47ec55e23b7a566bca51d2920562485#diff-5c3d6537a43ecae03014e118a7fe3321). But later it also gained `*_suppressed` methods and the difference between `silent` and `suppressed` is far from clear.
So rename `run` (which prints the command being run) to `run_verbose`. Then we can call the methods that just run a command and show its output but nothing extra `run` and `try_run`.
`run_verbose` (formerly `run`) is unused from what I can tell. Should I remove it?
r? @alexcrichton
Cc @Mark-Simulacrum
Also see https://github.com/rust-lang/rust/pull/63089#discussion_r308018890.
Rollup merge of #63121 - estebank:formatting-pos, r=alexcrichton
On `format!()` arg count mismatch provide extra info
When positional width and precision formatting flags are present in a
formatting string that has an argument count mismatch, provide extra
information pointing at them making it easiser to understand where the
problem may lay:
```
error: 4 positional arguments in format string, but there are 3 arguments
--> $DIR/ifmt-bad-arg.rs:78:15
|
LL | println!("{} {:.*} {}", 1, 3.2, 4);
| ^^ ^^--^ ^^ --- this parameter corresponds to the precision flag
| |
| this precision flag adds an extra required argument at position 1, which is why there are 4 arguments expected
|
= note: positional arguments are zero-based
= note: for information about formatting flags, visit https://doc.rust-lang.org/std/fmt/index.html
error: 4 positional arguments in format string, but there are 3 arguments
--> $DIR/ifmt-bad-arg.rs:81:15
|
LL | println!("{} {:07$.*} {}", 1, 3.2, 4);
| ^^ ^^-----^ ^^ --- this parameter corresponds to the precision flag
| | |
| | this precision flag adds an extra required argument at position 1, which is why there are 4 arguments expected
| this width flag expects an `usize` argument at position 7, but there are 3 arguments
|
= note: positional arguments are zero-based
= note: for information about formatting flags, visit https://doc.rust-lang.org/std/fmt/index.html
error: invalid reference to positional argument 7 (there are 3 arguments)
--> $DIR/ifmt-bad-arg.rs:84:18
|
LL | println!("{} {:07$} {}", 1, 3.2, 4);
| ^^^--^
| |
| this width flag expects an `usize` argument at position 7, but there are 3 arguments
|
= note: positional arguments are zero-based
= note: for information about formatting flags, visit https://doc.rust-lang.org/std/fmt/index.html
```
Rollup merge of #63107 - adrian-budau:master, r=alexcrichton
Added support for armv7-unknown-linux-gnueabi/musleabi
Fixes #63101
Some things that are not done and I hope someone can help me with:
* During the ci build of `armv7-unknown-linux-gnueabi` `openssl` must be built (to build cargo) but `openssl` does not yet support this target. This feels slightly like a chicken-and-egg problem, any feedback is welcome.
* Should I add any tests for any of these targets?
projects / rust.git / log