| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Avoid overlapping spans by only pointing at the arguments that are not
being used in the argument string. Enable libsyntax to have diagnostics
with multiple primary spans by accepting `Into<MultiSpan>` instead of
`Span`.
|
|
|
|
|
|
|
|
Introduce a new unified type that holds the expression precedence for
both AST and HIR nodes.
|
|
|
|
syntax: Rewrite parsing of impls
Properly parse impls for the never type `!`
Recover from missing `for` in `impl Trait for Type`
Prohibit inherent default impls and default impls of auto traits (https://github.com/rust-lang/rust/issues/37653#issuecomment-348687794, https://github.com/rust-lang/rust/issues/37653#issuecomment-348688785)
Change wording in more diagnostics to use "auto traits"
Fix some spans in diagnostics
Some other minor code cleanups in the parser
Disambiguate generics and qualified paths in impls (parse `impl <Type as Trait>::AssocTy { ... }`)
Replace the future-compatibility hack from https://github.com/rust-lang/rust/pull/38268 with actually parsing generic parameters
Add a test for https://github.com/rust-lang/rust/issues/46438
|
|
|
|
Properly parse impls for the never type `!`
Recover from missing `for` in `impl Trait for Type`
Prohibit inherent default impls and default impls of auto traits
Change wording in more diagnostics to use "auto traits"
Some minor code cleanups in the parser
|
|
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)
|
|
Remove `impl Foo for .. {}` in favor `auto trait Foo {}`
Rebase of https://github.com/rust-lang/rust/pull/46480 with restored parsing support.
|
|
|
|
|
|
Also refactored parsing auto traits.
|
|
No longer parse it.
Remove AutoTrait variant from AST and HIR.
Remove backwards compatibility lint.
Remove coherence checks, they make no sense for the new syntax.
Remove from rustdoc.
|
|
Remove deprecated unstable attribute #[simd]
The `#[simd]` attribute has been deprecated since c8b6d5b23cc8b2d43ece9f06252c7e98280fb8e5 back in 2015. Any nightly crates using it have had ample time to switch to `#[repr(simd)]`, and if they didn't they're likely broken by now anyway.
r? @eddyb
|
|
`struct` pattern parsing and diagnostic tweaks
- Recover from struct parse error on match and point out missing match
body.
- Point at struct when finding non-identifier while parsing its fields.
- Add label to "expected identifier, found {}" error.
Fix #15980.
|
|
r=estebank
type error method suggestions use whitelisted identity-like conversions
Previously, on a type mismatch (and if this wasn't preëmpted by a
higher-priority suggestion), we would look for argumentless methods
returning the expected type, and list them in a `help` note. This had two
major shortcomings: firstly, a lot of the suggestions didn't really make
sense (if you used a &str where a String was expected,
`.to_ascii_uppercase()` is probably not the solution you were hoping
for). Secondly, we weren't generating suggestions from the most useful
traits! We address the first problem with an internal
`#[rustc_conversion_suggestion]` attribute meant to mark methods that keep
the "same value" in the relevant sense, just converting the type. We
address the second problem by making `FnCtxt.probe_for_return_type` pass
the `ProbeScope::AllTraits` to `probe_op`: this would seem to be safe
because grep reveals no other callers of `probe_for_return_type`.
Also, structured suggestions are pretty and good for RLS and friends.
Unfortunately, the trait probing is still not all one would hope for: at a
minimum, we don't know how to rule out `into()` in cases where it wouldn't
actually work, and we don't know how to rule in `.to_owned()` where it
would. Issues #46459 and #46460 have been filed and are ref'd in a FIXME.
This is hoped to resolve #42929, #44672, and #45777.
|
|
Glued tokens can themselves be joint.
When gluing two tokens, the second of which is joint, the result should also be
joint.
This fixes an issue with joining three `Dot` tokens to make a `DotDotDot` - the
intermediate `DotDot` would not be joint and therefore we would not attempt to
glue the last `Dot` token, yielding `.. .` instead of `...`.
r? @jseyfried
|
|
Treat #[path] files as mod.rs files
Fixes https://github.com/rust-lang/rust/issues/46936, cc @briansmith, @SergioBenitez, @nikomatsakis.
This (insta-stable) change treats files included via `#[path = "bla.rs"] mod foo;` as though they were `mod.rs` files. Namely, it allows them to include `mod` statements and looks for the child modules in sibling directories, rather than in relative `modname/childmodule.rs` files as happens for non-`mod.rs` files.
This change makes the `non_modrs_mods` feature backwards compatible with the existing usage in https://github.com/briansmith/ring, several versions of which are currently broken in beta. If we decide to merge, this change should be backported to beta.
cc https://github.com/rust-lang/rust/issues/37872
r? @jseyfried
|
|
When gluing two tokens, the second of which is joint, the result should also be
joint.
This fixes an issue with joining three `Dot` tokens to make a `DotDotDot` - the
intermediate `DotDot` would not be joint and therefore we would not attempt to
glue the last `Dot` token, yielding `.. .` instead of `...`.
|
|
|
|
|
|
Rename ReprExtern to ReprC
… and similarily rename a few other field and locals that mentioned "extern repr".
|
|
zackmdavis:the_3rd_of_2_hardest_problems_in_computer_science, r=QuietMisdreavus
fix the doc-comment-decoration-trimming edge-case rustdoc ICE
This `horizontal_trim` function strips the leading whitespace from
doc-comments that have a left-asterisk-margin:
```
/**
* You know what I mean—
*
* comments like this!
*/
```
The index of the column of asterisks is `i`, and if trimming is deemed
possible, we slice each line from `i+1` to the end of the line. But if, in
particular, `i` was 0 _and_ there was an empty line (as in the example
given in the reporting issue), we ended up panicking trying to slice an
empty string from 0+1 (== 1).
Let's tighten our check to say that we can't trim when `i` is even the same
as the length of the line, not just when it's greater. (Any such cases
would panic trying to slice `line` from `line.len()+1`.)
Resolves #47197.
|
|
Add help message for incorrect pattern syntax
When I was getting started with rust I often made the mistake of using `||` instead of `|` to match multiple patterns and spent a long time staring at my code wondering what was wrong.
for example:
```
fn main() {
let x = 1;
match x {
1 || 2 => println!("1 or 2"),
_ => println!("Something else"),
}
}
```
If you compile this with current rustc you will see
```
error: expected one of `...`, `..=`, `..`, `=>`, `if`, or `|`, found `||`
--> test.rs:5:11
|
5 | 1 || 2 => println!("1 or 2"),
| -^^ unexpected token
| |
| expected one of `...`, `..=`, `..`, `=>`, `if`, or `|` here
error: aborting due to previous error
```
With my proposed change it will show:
```
error: unexpected token `||` after pattern
--> test.rs:5:11
|
5 | 1 || 2 => println!("1 or 2"),
| ^^
|
= help: did you mean to use `|` to specify multiple patterns instead?
error: aborting due to previous error
```
|
|
- Recover from struct parse error on match and point out missing match
body.
- Point at struct when finding non-identifier while parsing its fields.
- Add label to "expected identifier, found {}" error.
|
|
locals that mentioned "extern repr"
|
|
Upgrade `log` to `0.4` in multiple crates.
|
|
The `#[simd]` attribute has been deprecated since c8b6d5b23cc8b2d43ece9f06252c7e98280fb8e5 back in 2015. Any nightly crates using it have had ample time to switch to `#[repr(simd)]`, and if they didn't they're likely broken by now anyway.
|
|
Previously, on a type mismatch (and if this wasn't preëmpted by a
higher-priority suggestion), we would look for argumentless methods
returning the expected type, and list them in a `help` note.
This had two major shortcomings. Firstly, a lot of the suggestions didn't
really make sense (if you used a &str where a String was expected,
`.to_ascii_uppercase()` is probably not the solution you were hoping
for). Secondly, we weren't generating suggestions from the most useful
traits!
We address the first problem with an internal
`#[rustc_conversion_suggestion]` attribute meant to mark methods that keep
the "same value" in the relevant sense, just converting the type. We
address the second problem by making `FnCtxt.probe_for_return_type` pass
the `ProbeScope::AllTraits` to `probe_op`: this would seem to be safe
because grep reveals no other callers of `probe_for_return_type`.
Also, structured suggestions are preferred (because they're pretty, but
also for RLS and friends).
Also also, we make the E0055 autoderef recursion limit error use the
one-time-diagnostics set, because we can potentially hit the limit a lot
during probing. (Without this,
test/ui/did_you_mean/recursion_limit_deref.rs would report "aborting due to
51 errors").
Unfortunately, the trait probing is still not all one would hope for: at a
minimum, we don't know how to rule out `into()` in cases where it wouldn't
actually work, and we don't know how to rule in `.to_owned()` where it
would. Issues #46459 and #46460 have been filed and are ref'd in a FIXME.
This is hoped to resolve #42929, #44672, and #45777.
|
|
Support `extern` in paths
Implement the primary alternative to https://github.com/rust-lang/rust/pull/46613 + https://github.com/rust-lang/rust/pull/45771, achieving the same effect without requiring changes to other imports.
Both need to be experimentally evaluated before making further progress.
The PR also adds docs for all these related features into the unstable book.
cc https://github.com/rust-lang/rust/issues/44660
r? @nikomatsakis
|
|
|
|
|
|
This `horizontal_trim` function strips the leading whitespace from
doc-comments that have a left-asterisk-margin:
/**
* You know what I mean—
*
* comments like this!
*/
The index of the column of asterisks is `i`, and if trimming is deemed
possible, we slice each line from `i+1` to the end of the line. But if, in
particular, `i` was 0 _and_ there was an empty line (as in the example
given in the reporting issue), we ended up panicking trying to slice an
empty string from 0+1 (== 1).
Let's tighten our check to say that we can't trim when `i` is even the same
as the length of the line, not just when it's greater. (Any such cases
would panic trying to slice `line` from `line.len()+1`.)
Resolves #47197.
|
|
rustc: use {U,I}size instead of {U,I}s shorthands.
`Us`/`Is` come from a time when `us` and `is` were the literal suffixes that are now `usize` / `isize`.
r? @nikomatsakis
|
|
|
|
|
|
|
|
|
|
These no longer work now that Cargo changes the cwd of rustc while it's running.
Instead use an absolute path that's set by rustbuild.
|
|
|
|
|
|
|
|
Allow lifetimes in macros
This is a resurrection of PR #41927 which was a resurrection of #33135, which is intended to fix #34303.
In short, this allows macros_rules! to use :lifetime as a matcher to match 'lifetimes.
Still to do:
- [x] Feature gate
|
|
Resolves #47073.
|
|
|
|
|
|
|
|
|
