| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
Move Range*::contains to a single default impl on RangeBounds
Per the ongoing discussion in #32311.
This is my first PR to Rust (woo!), so I don't know if this requires an amendment to the original range_contains RFC, or not, or if we can just do a psuedo-RFC here. While this may no longer follow the explicit decision made in that RFC, I believe this better follows its spirit by adding the new contains method to all Ranges. It also allows users to be generic over all ranges and use this method without writing it themselves (my personal desired use case).
This also somewhat answers the unanswered question about Wrapping ranges in the above issue by instead just punting it to the question of what those types should return for start() & end(), or if they should implement RangeArgument at all. Those types could also implement their own contains method without implementing this trait, in which case the question remains the same.
This does add a new contains method to types that already implemented RangeArgument but not contains. These types are RangeFull, (Bound<T>, Bound<T>), (Bound<&'a T>, Bound<&'a T>). No tests have been added for these types yet. No inherent method has been added either.
r? @alexcrichton
|
|
This permits easier iteration without having to worry about warnings
being denied.
Fixes #49517
|
|
|
|
Bump the bootstrap compiler to 1.26.0 beta
Holy cow that's a lot of `cfg(stage0)` removed and a lot of new stable language
features!
|
|
|
|
Make queries thread safe
This makes queries thread safe by removing the query stack and making queries point to their parents. Queries write to the query map when starting and cycles are detected by checking if there's already an entry in the query map. This makes cycle detection O(1) instead of O(n), where `n` is the size of the query stack.
This is mostly corresponds to the method I described [here](https://internals.rust-lang.org/t/parallelizing-rustc-using-rayon/6606).
cc @rust-lang/compiler
r? @michaelwoerister
|
|
Holy cow that's a lot of `cfg(stage0)` removed and a lot of new stable language
features!
|
|
|
|
|
|
Always print `aborting due to n previous error(s)`
r? @michaelwoerister
|
|
their parents instead.
|
|
for multi-threaded code
|
|
|
|
|
|
This crate moves the compiler's error reporting to using the `termcolor` crate
from crates.io. Previously rustc used a super-old version of the `term` crate
in-tree which is basically unmaintained at this point, but Cargo has been using
`termcolor` for some time now and tools like `rg` are using `termcolor` as well,
so it seems like a good strategy to take!
Note that the `term` crate remains in-tree for libtest. Changing libtest will be
a bit tricky due to how the build works, but we can always tackle that later.
cc #45728
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add approximate suggestions for rustfix
This adds `span_approximate_suggestion()` that lets you emit a
suggestion marked as "non-machine applicable" in the JSON output. UI
users see no difference. This is for when rustc and clippy wish to
emit suggestions which will make sense to the reader (e.g. they may
have placeholders like `<type>`) but are not source-applicable, so that
rustfix/etc can ignore these.
fixes #39254
|
|
Rollup of 16 pull requests
- Successful merges: #47838, #47840, #47844, #47874, #47875, #47876, #47884, #47886, #47889, #47890, #47891, #47795, #47677, #47893, #47895, #47552
- Failed merges:
|
|
r=estebank
Avoid underflow in render_source_line
While testing rust-lang/rust#47655 I was able to make the compiler panic when it's compiled with debug assertions:
```shell
> rustc /dev/null --crate-type proc-macro
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.25.0-dev running on x86_64-apple-darwin
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'attempt to subtract with overflow', librustc_errors/emitter.rs:287:49
```
Without debug assertions the following warning is emitted:
```shell
> rustc /dev/null --crate-type proc-macro
warning: unused variable: `registrar`
--> /dev/null:0:1
|
|
= note: #[warn(unused_variables)] on by default
= note: to avoid this warning, consider using `_registrar` instead
```
The panic is due to the unused variable warning being spanned to `/dev/null:0:1`. When `render_source_line` subtracts 1 from the line number to look up the source line it panics due to underflow. Without debug assertions this would wrap and cause us to return a blank string instead.
Fix by explicitly testing for 0 and exiting early. I'm unsure how to automatically test this now that rust-lang/rust#46655 has been approved.
|
|
Highlight code on diagnostics when underlined
Highlight the label's span with the respective color:
<img width="692" alt="" src="https://user-images.githubusercontent.com/1606434/32411026-a1842482-c18d-11e7-9933-6510eefbad19.png">
Fix #42112.
|
|
Add line numbers and columns to error messages spanning multiple files
If an error message is emitted that spans several files, only the
primary file currently has line and column data attached. This is
useful information, even in files other than the one in which the error
occurs. We can often work out which line and column the error
corresponds to in other files — in this case it is helpful to add them
(in the case of ambiguity, the first relevant line/column is picked,
which is still helpful than none).
|
|
|
|
This adds `span_approximate_suggestion()` that lets you emit a
suggestion marked as "approximate" in the JSON output. UI
users see no difference. This is for when rustc and clippy wish to
emit suggestions which will make sense to the reader (e.g. they may
have placeholders like `<type>`) but are not source-applicable, so that
rustfix/etc can ignore these.
fixes #39254
|
|
|
|
|
|
For E0277 on `for` loops, point at the "head" expression
When E0277's span points at a `for` loop, the actual issue is in the
element being iterated. Instead of pointing at the entire loop, point
only at the first line (when possible) so that the span ends in the
element for which E0277 was triggered.
|
|
|
|
If an error message is emitted that spans several files, only the
primary file currently has line and column data attached. This is
useful information, even in files other than the one in which the error
occurs. We can often work out which line and column the error
corresponds to in other files — in this case it is helpful to add them
(in the case of ambiguity, the first relevant line/column is picked,
which is still helpful than none).
|
|
|
|
errors
|
|
|
|
While testing rust-lang/rust#47655 I was able to make the compiler panic
when it's compiled with debug assertions:
```shell
> rustc /dev/null --crate-type proc-macro
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.25.0-dev running on x86_64-apple-darwin
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'attempt to subtract with overflow', librustc_errors/emitter.rs:287:49
```
Without debug assertions the following warning is emitted:
```shell
> rustc /dev/null --crate-type proc-macro
warning: unused variable: `registrar`
--> /dev/null:0:1
|
|
= note: #[warn(unused_variables)] on by default
= note: to avoid this warning, consider using `_registrar` instead
```
The panic is due to the unused variable warning being spanned to
`/dev/null:0:1`. When `render_source_line` subtracts 1 from the line
number to look up the source line it panics due to underflow. Without
debug assertions this would wrap and cause us to return a blank string
instead.
Fix by explicitly testing for 0 and exiting early. I'm unsure how to
automatically test this now that rust-lang/rust#46655 has been approved.
|
|
|
|
fix mispositioned span
This fixes #47377
The output now looks like this
```
error[E0369]: binary operation `+` cannot be applied to type `&str`
--> h.rs:3:11
|
3 | let _a = b + ", World!";
| ^^^^^^^^^^^^^^ `+` can't be used to concatenate two `&str` strings
help: `to_owned()` can be used to create an owned `String` from a string reference. String concatenation appends the string on the right to the string on the left and may require reallocation. This requires ownership of the string on the left
|
3 | let _a = b.to_owned() + ", World!";
| ^^^^^^^^^
error: aborting due to previous error
```
For the case when emojis are involved, it gives the new output for proper indentation.
But for an indentation as follows,
```
fn main() {
let b = "hello";
let _a = b + ", World!";
}
```
it still mispositions the span
```
3 | println!("🦀🦀🦀🦀🦀"); let _a = b + ", World!";
| ^^^^^^^^^^^^^^ `+` can't be used to concatenate two `&str` strings
|
3 | println!("🦀🦀🦀🦀🦀"); let _a = b.to_owned() + ", World!";
| ^^^^^^^
error: aborting due to previous erro
```
cc @estebank @est31
|
|
Use correct line offsets for doctests
Not yet tested.
This doesn't handle char positions. It could if I collected a map of char offsets and lines, but this is a bit more work and requires hooking into the parser much more (unsure if it's possible).
r? @QuietMisdreavus
(fixes #45868)
|
|
|
|
|
|
|
|
When external tools like `rustfmt` calls to `reset_err_count` for handler
reusing, it will set the error count on the handler to 0, but since
https://github.com/rust-lang/rust/pull/47146 the handler will contain
status that will prevent the error count to be bumped if this handler is
reused.
This caused `rustfmt` idempotency tests to fail:
https://github.com/rust-lang-nursery/rustfmt/issues/2338
Fixes: https://github.com/rust-lang-nursery/rustfmt/issues/2338
|
|
This ensures that if we emit the same diagnostic twice, the error count will
match the real number of errors shown to the user.
Fixes #42106
|
|
|
