| Age | Commit message (Collapse) | Author | Lines |
|---|
|
`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
|
|
|
|
|
|
As per #26009 this PR implements a new collation system for extended-error metadata. I've tried to keep it as simple as possible for now, so there's no uniqueness checking and minimal modularity.
Although using a lint was discussed in #26009 I decided against this because it would require converting the AST output from the plugin back into an internal data-structure. Emitting the metadata from within the plugin prevents this double-handling. We also didn't identify this as the source of the failures last time, although something untoward was definitely happening... With that in mind I would like as much feedback as possible on this before it's merged, I don't want to break the bots again!
I've successfully built for my host architecture and I'm building an ARM cross-compiler now to test my assumptions about the various `CFG` variables. Despite the confusing name of `CFG_COMPILER_HOST_TRIPLE` it is actually the compile time target triple, as explained in `mk/target.mk`.
```
# This is the compile-time target-triple for the compiler. For the compiler at
# runtime, this should be considered the host-triple. More explanation for why
# this exists can be found on issue #2400
export CFG_COMPILER_HOST_TRIPLE
```
CC @pnkfelix @brson @nrc @alexcrichton
Closes #25705, closes #26009.
|
|
It now says '#[feature] may not be used on the stable release channel'.
I had to convert this error from a lint to a normal compiler error.
I left the lint previously-used for this in place since removing it is
a breaking change. It will just go unused until the end of time.
Fixes #24125
|
|
|
|
It now says '#[feature] may not be used on the stable release channel'.
I had to convert this error from a lint to a normal compiler error.
I left the lint previously-used for this in place since removing it is
a breaking change. It will just go unused until the end of time.
Fixes #24125
|
|
|
|
This commit shards the all-encompassing `core`, `std_misc`, `collections`, and `alloc` features into finer-grained components that are much more easily opted into and tracked. This reflects the effort to push forward current unstable APIs to either stabilization or removal. Keeping track of unstable features on a much more fine-grained basis will enable the library subteam to quickly analyze a feature and help prioritize internally about what APIs should be stabilized.
A few assorted APIs were deprecated along the way, but otherwise this change is just changing the feature name associated with each API. Soon we will have a dashboard for keeping track of all the unstable APIs in the standard library, and I'll also start making issues for each unstable API after performing a first-pass for stabilization.
|
|
r? @nrc, because breakage was caused by https://github.com/rust-lang/rust/pull/25318
|
|
|
|
This commit also deprecates the `as_string` and `as_slice` free functions in the
`string` and `vec` modules.
|
|
This commit shards the broad `core` feature of the libcore library into finer
grained features. This split groups together similar APIs and enables tracking
each API separately, giving a better sense of where each feature is within the
stabilization process.
A few minor APIs were deprecated along the way:
* Iterator::reverse_in_place
* marker::NoCopy
|
|
PR for #26128.
Improves codegen in deriving by utilizing the discriminant_value intrinsic.
I have a more detailed comment on the changes in a comment on the issue [here](https://github.com/rust-lang/rust/issues/26128#issuecomment-111509863)
### Old
```
running 7 tests
test large_c_like ... bench: 2,694,129 ns/iter (+/- 5,170)
test large_c_like_ord ... bench: 2,723,521 ns/iter (+/- 9,098)
test test1_partial_eq ... bench: 2,439,317 ns/iter (+/- 2,135)
test test1_partial_ord ... bench: 2,499,114 ns/iter (+/- 55,766)
test test2_partial_eq ... bench: 3,562,815 ns/iter (+/- 45,590)
test test2_partial_ord ... bench: 3,398,306 ns/iter (+/- 22,180)
test test_match_success ... bench: 1,509,267 ns/iter (+/- 1,982)
```
### New
```
running 7 tests
test large_c_like ... bench: 286,509 ns/iter (+/- 474)
test large_c_like_ord ... bench: 286,666 ns/iter (+/- 8,756)
test test1_partial_eq ... bench: 286,584 ns/iter (+/- 2,789)
test test1_partial_ord ... bench: 286,470 ns/iter (+/- 516)
test test2_partial_eq ... bench: 2,228,997 ns/iter (+/- 34,191)
test test2_partial_ord ... bench: 1,731,699 ns/iter (+/- 21,756)
test test_match_success ... bench: 1,509,630 ns/iter (+[- 3,765)
```
[Benchmark](https://gist.github.com/Marwes/7c0b3468d0cae972a2b4)
|
|
|
