| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Allow defaultness on trait items syntactically.
|
|
When refering to or suggesting raw identifiers, refer to them with `r#`.
Fix #65634.
|
|
|
|
Refactor `parse_enum_item` to use `parse_delim_comma_seq`
Followup after https://github.com/rust-lang/rust/pull/66641
Some errors got more verbose but I think they make sense with the help message.
|
|
|
|
Rework raw ident suggestions
Use heuristics to determine whethersuggesting raw identifiers is
appropriate.
Account for raw identifiers when printing a path in a `use` suggestion.
Fix #66126.
|
|
Use heuristics to determine whethersuggesting raw identifiers is
appropriate.
Account for raw identifiers when printing a path in a `use` suggestion.
|
|
Point at type in `let` assignment on type errors
Fix #61067.
|
|
*Syntactically* permit visibilities on trait items & enum variants
Fixes #65041
Suppose we have `$vis trait_item` or `$vis enum_variant` and `$vis` is a `:vis` macro fragment. Before this PR, this would fail to parse. This is now instead allowed as per language team consensus in https://github.com/rust-lang/rust/issues/65041#issuecomment-538105286. (See added tests for elaboration.)
Moreover, we now also permit visibility modifiers on trait items & enum variants *syntactically* but reject them with semantic checks (in `ast_validation`):
```rust
#[cfg(FALSE)]
trait Foo { pub fn bar(); } // OK
#[cfg(FALSE)]
enum E { pub U } // OK
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add more tests for fixed ICEs
Closes #36122 (fixed in 1.20.0)
Closes #58094 (fixed in #66054)
Also, fix mistaken test case, from #30904 to #30906 (cc @eddyb)
r? @Centril
|
|
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
|
|
|
|
|
|
parser: don't use `unreachable!()` in `fn unexpected`.
Fixes #66357
r? @estebank
|
|
Tweak non-char/numeric in range pattern diagnostic
Fixes #66283
r? @estebank
|
|
|
|
|
|
|
|
|
|
Remove "here" from "expected one of X here"
|
|
A scheme for more macro-matcher friendly pre-expansion gating
Pre-expansion gating will now avoid gating macro matchers that did not result in `Success(...)`. That is, the following is now OK despite `box 42` being a valid `expr` and that form being pre-expansion gated:
```rust
macro_rules! m {
($e:expr) => { 0 }; // This fails on the input below due to `, foo`.
(box $e:expr, foo) => { 1 }; // Successful matcher, we should get `2`.
}
fn main() {
assert_eq!(1, m!(box 42, foo));
}
```
Closes https://github.com/rust-lang/rust/issues/65846.
r? @petrochenkov
cc @Mark-Simulacrum
|
|
|
|
|
|
|
|
|
|
|
|
syntax: Avoid span arithmetic for delimiter tokens
The +/-1 logic is from the time where the whole group had a single span and the delimiter spans had to be calculated from it.
Now the delimiters have their own spans which are constructed by lexer or proc macro API and can be used directly.
If those spans are not perfect, then it should be fixed by tweaking the corresponding lexer logic rather than by trying to add or substract `1` from the span boundaries.
Fixes https://github.com/rust-lang/rust/issues/62524
r? @estebank
|
|
Reduce amount of errors given unclosed delimiter
When in a file with a non-terminated item, catch the error and consume
the block instead of trying to recover it on a more granular way in order to
reduce the amount of unrelated errors that would be fixed after adding
the missing closing brace. Also point out the possible location of the
missing closing brace.
Fix #63690.
|
|
|
|
Partially revert the early feature-gatings added in #65742.
The intent here is to address #65860 ASAP (in time for beta, ideally), while leaving as much of #65742 around as possible, to make it easier to re-enable later.
Therefore, I've only kept the parts of the revert that re-add the old (i.e. non-early) feature-gating checks that were removed in #65742, and the test reverts.
I've disabled the new early feature-gating checks from #65742 entirely for now, but it would be easy to put them behind a `-Z` flag, or turn them into warnings, which would allow us to keep tests for both the early and late versions of the checks - assuming that's desirable.
cc @nikomatsakis @Mark-Simulacrum @Centril
|
|
This reverts commit 665a876e307933c6480a6c55a3e38e88937aff2c.
|
|
|
|
|
|
When in a file with a non-terminated item, catch the error and consume
the block instead of trying to recover it more granularly in order to
reduce the amount of unrelated errors that would be fixed after adding
the missing closing brace. Also point out the possible location of the
missing closing brace.
|
|
Add new EFIAPI ABI
Fixes #54527
Adds a new ABI, "efiapi", which reflects the calling convention as specified by [the current spec UEFI spec](https://uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf#G6.999903). When compiling for x86_64, we should select the `win64` ABI, while on all other architectures (Itanium, x86, ARM and ARM64 and RISC-V), we should select the `C` ABI.
Currently, this is done by just turning it into the C ABI everywhere except on x86_64, where it's turned into the win64 ABI. Should we prevent this ABI from being used on unsupported architectures, and if so, how would this be done?
|
|
Use heuristics to recover parsing of missing `;`
- Detect `,` and `:` typos where `;` was intended.
- When the next token could have been the start of a new statement,
detect a missing semicolon.
Fix #48160, fix #44767 (after adding note about statements).
|
|
|
|
|
|
- Detect `,` and `:` typos where `;` was intended.
- When the next token could have been the start of a new statement,
detect a missing semicolon.
|
|
Point at the span for the definition of ADTs internal to the current
crate.
Look at the leading char of the ident to determine whether we're
expecting a likely fn or any of a fn, a tuple struct or a tuple variant.
Turn fn `add_typo_suggestion` into a `Resolver` method.
|
|
Increase spacing for suggestions in diagnostics
Make the spacing between the code snippet and verbose structured
suggestions consistent with note and help messages.
r? @Centril
|
|
Adds a new ABI for the EFIAPI calls. This ABI should reflect the latest
version of the UEFI specification at the time of commit (UEFI spec 2.8,
URL below). The specification says that for x86_64, we should follow the
win64 ABI, while on all other supported platforms (ia32, itanium, arm,
arm64 and risc-v), we should follow the C ABI.
To simplify the implementation, we will simply follow the C ABI on all
platforms except x86_64, even those technically unsupported by the UEFI
specification.
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
|
|
Make the spacing between the code snippet and verbose structured
suggestions consistent with note and help messages.
|
