| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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
|
|
|
|
|
|
See commits for details
|
|
This basically only affects modules which are empty (or only contain comments).
Closes #26755
|
|
|
|
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.
|
|
This closes https://github.com/rust-lang/rust/issues/27042.
I'd love to know if there's a way to make a regression test for this!
|
|
|
|
|
|
`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.
|
|
Now the macro argument list can be finished by a comma (not sure this is correct english...).
cc @tamird
r? @bluss
|
|
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.
|
|
|
|
|
|
|
|
This commit expands the follow set of the `ty` and `path` macro fragments to
include the semicolon token as well. A semicolon is already allowed after these
tokens, so it's currently a little too restrictive to not have a semicolon
allowed. For example:
extern {
fn foo() -> i32; // semicolon after type
}
fn main() {
struct Foo;
Foo; // semicolon after path
}
|
|
Inspired by the now-mysteriously-closed https://github.com/rust-lang/rust/pull/26782.
This PR introduces better error messages when unicode escapes have invalid format (e.g. `\uFFFF`). It also makes rustc always tell the user that escape may not be used in byte-strings and bytes and fixes some spans to not include unecessary characters and include escape backslash in some others.
|
|
This makes the functionality usable from outside the parser
|
|
|
|
This commit expands the follow set of the `ty` and `path` macro fragments to
include the semicolon token as well. A semicolon is already allowed after these
tokens, so it's currently a little too restrictive to not have a semicolon
allowed. For example:
extern {
fn foo() -> i32; // semicolon after type
}
fn main() {
struct Foo;
Foo; // semicolon after path
}
|
|
|
|
|
|
This improves diagnostic messages when \u escape is used incorrectly and { is
missing. Instead of saying “unknown character escape: u”, it will now report
that unicode escape sequence is incomplete and suggest what the correct syntax
is.
|
|
r? @huonw
|
|
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.
|
|
In a followup to PR #26849, improve one more location for I/O where
we can use `Vec::resize` to ensure better performance when zeroing
buffers.
Use the `vec![elt; n]` macro everywhere we can in the tree. It replaces
`repeat(elt).take(n).collect()` which is more verbose, requires type
hints, and right now produces worse code. `vec![]` is preferable for vector
initialization.
The `vec![]` replacement touches upon one I/O path too, Stdin::read
for windows, and that should be a small improvement.
r? @alexcrichton
|
|
The common pattern `iter::repeat(elt).take(n).collect::<Vec<_>>()` is
exactly equivalent to `vec![elt; n]`, do this replacement in the whole
tree.
(Actually, vec![] is smart enough to only call clone n - 1 times, while
the former solution would call clone n times, and this fact is
virtually irrelevant in practice.)
|
|
Fixes #23302.
Note that there's an odd situation regarding the following, most likely due to some inadequacy in `const_eval`:
```rust
enum Y {
A = 1usize,
B,
}
```
In this case, `Y::B as usize` might be considered a constant expression in some cases, but not others. (See #23513, for a related problem where there is only one variant, with no discriminant, and it doesn't behave nicely as a constant expression either.)
Most of the complexity in this PR is basically future-proofing, to ensure that when `Y::B as usize` is fully made to be a constant expression, it can't be used to set `Y::A`, and thus indirectly itself.
|
|
|
|
|
|
in their spans
|
|
|
|
This takes an issue number and points people to it in the printed error
message. This commit does not make it an error to have no `issue` field.
|
|
This takes an issue number and points people to it in the printed error
message. This commit does not make it an error to have no `issue` field.
|
|
|
|
This makes it somewhat more aggressive, so this is kind-of a [breaking-change] for these compiling with `#[deny(unused_mut)]`.
r? @pnkfelix
|
|
This makes the functionality usable from outside the parser
|
|
|
|
I've mirrored them out to crates (bit-vec and bit-set) that build on stable.
(not sure if this actually correctly deprecates them in std)
|
|
|
|
closes #25037
closes #11715
r? @nrc
|
|
Fixes #26332
|
|
|
|
Fixes #11715
|
|
Uncertain if this is the desired effect/strategy/testing.
r? @aturon
|
