Fixes#25022
This adapts the deriving mechanism to not repeat bounds for the same type parameter. To give an example: for the following code:
```rust
#[derive(Clone)]
pub struct FlatMap<I, U: IntoIterator, F> {
iter: I,
f: F,
frontiter: Option<U::IntoIter>,
backiter: Option<U::IntoIter>,
}
```
the latest nightly generates the following impl signature:
```rust
impl <I: ::std::clone::Clone,
U: ::std::clone::Clone + IntoIterator,
F: ::std::clone::Clone>
::std::clone::Clone for FlatMap<I, U, F> where
I: ::std::clone::Clone,
F: ::std::clone::Clone,
U::IntoIter: ::std::clone::Clone,
U::IntoIter: ::std::clone::Clone
```
With these changes, the signature changes to this:
```rust
impl <I, U: IntoIterator, F> ::std::clone::Clone for FlatMap<I, U, F> where
I: ::std::clone::Clone,
F: ::std::clone::Clone,
U::IntoIter: ::std::clone::Clone
```
(Nothing in the body of the impl changes)
Note that the second impl is more permissive, as it doesn't have a `Clone` bound on `U` at all. There was a compile-fail test that failed due to this. I don't understand why we would want the old behaviour (and nobody on IRC could tell me either), so please tell me if there is a good reason that I missed.
Improves diagnostics in various locations, namely:
* A few error messages that orignally were a mix of an error message and suggestion how to fix it have been split up into two messages: an error and help/hint.
* Never report “illegal”. Fixes https://github.com/rust-lang/rust/issues/27288
`EmitterWriter::print_maybe_styled` was basically always used with `format!`, so this macro makes some code cleaner. It should also remove some unnecessary allocations (most `print_maybe_styled` invocations allocated a `String` previously, whereas the new macro uses `write_fmt` to write the formatted string directly to the terminal).
This probably could have been part of #26838, but it’s too late now. It’s also rebased on #26838’s branch because otherwise pretty much all of the changes in this PR would conflict with the other PR’s changes.
This does two things:
* removes ast::LocalSource, where only one variant was used because for-loop expansion has changed. One reason that this slipped into here is because the code in `check_local` which checks for `LocalSource::LocalFor` would report the same error as in `check_exhaustive` while using the wrong error code (E0005 instead of E0297).
* silences the warning about already used diagnostic code E0005 (fixes#27279)
passes `make check` locally.
`LocalSource` indicated wether a let binding originated from for-loop desugaring to enable specialized error messages, but for-loop expansion has changed and this is now achieved through `MatchSource::ForLoopDesugar`.
***Edit: Fixed now.*** I'm pretty sure the way I'm using LLVMReplaceAllUsesWith here is
unsafe... but before I figure out how to fix that, I'd like a
reality-check: is this actually useful?
This introduces a test for #23389 and improves the error behaviour to treat the malformed LHS as an error, not a compiler bug.
The parse phase that precedes the call to `check_lhs_nt_follows` could possibly be enhanced to police the format itself (which the old code suggests was the original intention), but I'm not sure that's any nicer than just parsing the matcher as generic rust code and then policing the specific requirements for being a macro matcher afterwards (as this does).
Fixes#23389
Macro desugaring of `in PLACE { BLOCK }` into "simpler" expressions following the in-development "Placer" protocol.
Includes Placer API that one can override to integrate support for `in` into one's own type. (See [RFC 809].)
[RFC 809]: https://github.com/rust-lang/rfcs/blob/master/text/0809-box-and-in-for-stdlib.md
Part of #22181
Replaced PR #26180.
Turns on the `in PLACE { BLOCK }` syntax, while leaving in support for the old `box (PLACE) EXPR` syntax (since we need to support that at least until we have a snapshot with support for `in PLACE { BLOCK }`.
(Note that we are not 100% committed to the `in PLACE { BLOCK }` syntax. In particular I still want to play around with some other alternatives. Still, I want to get the fundamental framework for the protocol landed so we can play with implementing it for non `Box` types.)
----
Also, this PR leaves out support for desugaring-based `box EXPR`. We will hopefully land that in the future, but for the short term there are type-inference issues injected by that change that we want to resolve separately.
(Over time the stability checking has gotten more finicky; in
particular one must attach the (whole) span of the original `in PLACE
BLOCK` expression to the injected references to unstable paths, as
noted in the comments.)
call `push_compiler_expansion` during the placement-`in` expansion.
Even after expansion, the generated expressions still track depth of
such pushes (i.e. how often you have "pushed" without a corresponding
"pop"), and we add a rule that in a context with a positive
`push_unsafe!` depth, it is effectively an `unsafe` block context.
(This way, we can inject code that uses `unsafe` features, but still
contains within it a sub-expression that should inherit the outer
safety checking setting, outside of the injected code.)
This is a total hack; it not only needs a feature-gate, but probably
should be feature-gated forever (if possible).
ignore-pretty in test/run-pass/pushpop-unsafe-okay.rs
So if a filemap's last byte is at position n in the codemap, then n+1 will not refer to any filemap, and the next filemap will begin an n+2.
This is useful for empty files, it means that every file (even empty ones) has a byte in the codemap.
Closes#23301, #26504
This commit ensures that the rustc thread does not leak a panic message whenever
a call to `fatal` happens. This already happens for the main rustc thread as
part of the `rustc_driver::monitor` function, but the compiler also spawns
threads for other operations like `-C codegen-units`, and sometimes errors are
emitted on these threads as well. To ensure that there's a consistent
error-handling experience across threads this unifies these two to never print
the panic message in the case of a normal and expected fatal error.
This should also fix the flaky `asm-src-loc-codegen-units.rs` test as the output
is sometimes garbled if diagnostics are printed while the panic message is also
being printed.
Fixes#23812 by stripping the decoration when desugaring macro doc comments into #[doc] attributes, and detects whether the attribute should be inner or outer style and outputs the appropriate token tree.
This commit ensures that the rustc thread does not leak a panic message whenever
a call to `fatal` happens. This already happens for the main rustc thread as
part of the `rustc_driver::monitor` function, but the compiler also spawns
threads for other operations like `-C codegen-units`, and sometimes errors are
emitted on these threads as well. To ensure that there's a consistent
error-handling experience across threads this unifies these two to never print
the panic message in the case of a normal and expected fatal error.
This should also fix the flaky `asm-src-loc-codegen-units.rs` test as the output
is sometimes garbled if diagnostics are printed while the panic message is also
being printed.
`EmitterWriter::print_maybe_styled` was basically always used with `format!`, so
this macro makes some code cleaner. It should also remove some unnecessary
allocations (most `print_maybe_styled` invocations allocated a `String`
previously, whereas the new macro uses `write_fmt` to write the formatted string
directly to the terminal).
This probably could have been part of #26838, but it’s too late now.
Escape sequences in documentation comments must not be parsed as a normal string when expanding a macro, otherwise some innocent but invalid-escape-sequence-looking comments will trigger an ICE.
Although this commit replaces normal string literals with raw string literals in macro expansion, this shouldn't be much a problem considering documentation comments are converted into attributes before being passed to a macro anyways.
Fixes#25929.
Fixes#25943.
