Guard against overflow in `codemap::span_to_lines`.
(Revised/expanded version of PR #24976)
Make `span_to_lines` to return a `Result`.
In `diagnostic`, catch `Err` from `span_to_lines` and print `"(unprintable span)"` instead.
----
There a number of recent issues that report the bug here. See e.g. #24761 and #24954.
This change *might* fix them. However, that is *not* its main goal. The main goals are:
1. Make it possible for callers to recover from an error here, and
2. Insert a more conservative check, in that we are also checking that the files match up.
----
As a drive-by, fix#24997 , which was causing my attempts to `make check-stage1` on an `--enable-debug` build to fail.
Make `span_to_lines` to return a `Result`.
(This is better than just asserting internally, since it allows caller
to decide if they can recover from the problem.)
Added type alias for `FileLinesResult` returned by `span_to_lines`.
Update embedded unit test to reflect `span_to_lines` signature change.
In diagnostic, catch `Err` from `span_to_lines` and print
`"(internal compiler error: unprintable span)"` instead.
----
There a number of recent issues that report the bug here. See
e.g. #24761 and #24954.
This change *might* fix them. However, that is not its main goal.
The main goals are:
1. Make it possible for callers to recover from an error here, and
2. Insert a more conservative check, in that we are
also checking that the files match up.
Adds an `attrs` field to `FieldInfo` which lets one check the attributes on
a field whilst expanding.
This lets deriving plugins be more robust, for example providing the ability to
"ignore" a field for the purpose of deriving, or perhaps handle the field a
different way.
r? @huonw
collections: Implement String::drain(range) according to RFC 574
`.drain(range)` is unstable and under feature(collections_drain).
This adds a safe way to remove any range of a String as efficiently as
possible.
As noted in the code, this drain iterator has none of the memory safety
issues of the vector version.
RFC tracking issue is #23055
Hi! While researching stuff for the reference and the grammar, I came across a few mentions of using the `priv` keyword that was removed in 0.11.0 (#13547, #8122, rust-lang/rfcs#26, [RFC 0026](https://github.com/rust-lang/rfcs/blob/master/text/0026-remove-priv.md)).
One occurrence is a mention in the reference, a few are in comments, and a few are marking test functions. I left the test that makes sure you can't name an ident `priv` since it's still a reserved keyword. I did a little grepping around for `priv `, priv in backticks, `Private` etc and I think the remaining instances are fine, but if anyone knows anywhere in particular I should check for any other lingering mentions of `priv`, please let me know and I would be happy to! 🍂🌊
I've been working on improving the diagnostic registration system so that it can:
* Check uniqueness of error codes *across the whole compiler*. The current method using `errorck.py` is prone to failure as it relies on simple text search - I found that it breaks when referencing an error's ident within a string (e.g. `"See also E0303"`).
* Provide JSON output of error metadata, to eventually facilitate HTML output, as well as tracking of which errors need descriptions. The current schema is:
```
<error code>: {
"description": <long description>,
"use_site": {
"filename": <filename where error is used>,
"line": <line in file where error is used>
}
}
```
[Here's][metadata-dump] a pretty-printed sample dump for `librustc`.
One thing to note is that I had to move the diagnostics arrays out of the diagnostics modules. I really wanted to be able to capture error usage information, which only becomes available as a crate is compiled. Hence all invocations of `__build_diagnostics_array!` have been moved to the ends of their respective `lib.rs` files. I tried to avoid moving the array by making a plugin that expands to nothing but couldn't invoke it in item position and gave up on hackily generating a fake item. I also briefly considered using a lint, but it seemed like it would impossible to get access to the data stored in the thread-local storage.
The next step will be to generate a web page that lists each error with its rendered description and use site. Simple mapping and filtering of the metadata files also allows us to work out which error numbers are absent, which errors are unused and which need descriptions.
[metadata-dump]: https://gist.github.com/michaelsproul/3246846ff1bea71bd049
Closes#17841.
The majority of the work should be done, e.g. trait and inherent impls, different forms of UFCS syntax, defaults, and cross-crate usage. It's probably enough to replace the constants in `f32`, `i8`, and so on, or close to good enough.
There is still some significant functionality missing from this commit:
- ~~Associated consts can't be used in match patterns at all. This is simply because I haven't updated the relevant bits in the parser or `resolve`, but it's *probably* not hard to get working.~~
- Since you can't select an impl for trait-associated consts until partway through type-checking, there are some problems with code that assumes that you can check constants earlier. Associated consts that are not in inherent impls cause ICEs if you try to use them in array sizes or match ranges. For similar reasons, `check_static_recursion` doesn't check them properly, so the stack goes ka-blooey if you use an associated constant that's recursively defined. That's a bit trickier to solve; I'm not entirely sure what the best approach is yet.
- Dealing with consts associated with type parameters will raise some new issues (e.g. if you have a `T: Int` type parameter and want to use `<T>::ZERO`). See rust-lang/rfcs#865.
- ~~Unused associated consts don't seem to trigger the `dead_code` lint when they should. Probably easy to fix.~~
Also, this is the first time I've been spelunking in rustc to such a large extent, so I've probably done some silly things in a couple of places.
This changes the `ToTokens` implementations for expressions, statements,
etc. with almost-trivial ones that produce `Interpolated(*Nt(...))`
pseudo-tokens. In this way, quasiquote now works the same way as macros
do: already-parsed AST fragments are used as-is, not reparsed.
The `ToSource` trait is removed. Quasiquote no longer involves
pretty-printing at all, which removes the need for the
`encode_with_hygiene` hack. All associated machinery is removed.
A new `Nonterminal` is added, NtArm, which the parser now interpolates.
This is just for quasiquote, not macros (although it could be in the
future).
`ToTokens` is no longer implemented for `Arg` (although this could be
added again) and `Generics` (which I don't think makes sense).
This breaks any compiler extensions that relied on the ability of
`ToTokens` to turn AST fragments back into inspectable token trees. For
this reason, this closes#16987.
As such, this is a [breaking-change].
Fixes#16472.
Fixes#15962.
Fixes#17397.
Fixes#16617.
As part of the audit for #22820 the following feature gate tests have been
added:
* `negate_unsigned`
* `on_unimplemented`
* `optin_builtin_traits`
* `plugin`
* `rustc_attrs`
* `rustc_diagnostic_macros`
* `slice_patterns`
In addition some feature gate error message typos fixed.
Changes the style guidelines regarding unit tests to recommend using a
sub-module named "tests" instead of "test" for unit tests as "test"
might clash with imports of libtest.
This PR uses the inline error suggestions introduced in #24242 to modify a few existing `help` messages. The new errors look like this:
foobar.rs:5:12: 5:25 error: expected a path on the left-hand side of `+`,
not `&'static Copy` [E0178]
foobar.rs:5 let x: &'static Copy + 'static;
^~~~~~~~~~~~~
foobar.rs:5:12: 5:35 help: try adding parentheses (per RFC 438):
foobar.rs: let x: &'static (Copy + 'static);
foobar.rs:2:13: 2:23 error: cast to unsized type: `&_` as `core::marker::Copy`
foobar.rs:2 let x = &1 as Copy;
^~~~~~~~~~
foobar.rs:2:19: 2:23 help: try casting to a reference instead:
foobar.rs: let x = &1 as &Copy;
foobar.rs:7:24: 7:25 error: expected expression, found `;`
foobar.rs:7 let x = box (1 + 1);
^
foobar.rs:7:13: 7:16 help: try using `box()` instead:
foobar.rs: let x = box() (1 + 1);
This also modifies compiletest to give the ability to directly test suggestions given by error messages.
This commit removes all the old casting/generic traits from `std::num` that are
no longer in use by the standard library. This additionally removes the old
`strconv` module which has not seen much use in quite a long time. All generic
functionality has been supplanted with traits in the `num` crate and the
`strconv` module is supplanted with the [rust-strconv crate][rust-strconv].
[rust-strconv]: https://github.com/lifthrasiir/rust-strconv
This is a breaking change due to the removal of these deprecated crates, and the
alternative crates are listed above.
[breaking-change]
