| Age | Commit message (Collapse) | Author | Lines |
|
Improve format string errors
Point at format string position inside the formatting string:
```
error: invalid format string: unmatched `}` found
--> $DIR/format-string-error.rs:21:22
|
LL | let _ = format!("}");
| ^ unmatched `}` in format string
```
Explain that argument names can't start with an underscore:
```
error: invalid format string: invalid argument name `_foo`
--> $DIR/format-string-error.rs:15:23
|
LL | let _ = format!("{_foo}", _foo = 6usize);
| ^^^^ invalid argument name in format string
|
= note: argument names cannot start with an underscore
```
Fix #23476.
The more accurate spans will only be seen when using `format!` directly, when using `println!` the diagnostics machinery makes the span be the entire statement.
|
|
https://www.doi.org/doi_handbook/3_Resolution.html#3.8
|
|
It only has a single use, within code handling indented block comments.
We can replace that with the new `FileMap::col_pos()`, which computes
the col position (BytePos instead of CharPos) based on the record of the
last newline char (which we already record).
This is actually an improvement, because
`trim_whitespace_prefix_and_push_line()` was using `col`, which is a
`CharPos`, as a slice index, which is a byte/char confusion.
|
|
Because `bump()` is hot.
|
|
|
|
Allocate Symbol strings from an arena
This is an alternative to https://github.com/rust-lang/rust/pull/50549
cc @nnethercote
r? @michaelwoerister
|
|
- Point at format string position inside the formatting string
- Explain that argument names can't start with an underscore
|
|
|
|
Because they are simple and hot.
This change speeds up some incremental runs of a few rustc-perf
benchmarks, the best by 3%.
|
|
Because they are (a) trivial, and (b) super hot.
This change speeds up most rustc-benchmarks, the best by 5%.
|
|
Add some utilities to `libsyntax`
Adds a few functions to `Mark` and `Span` that I found useful in an upcoming refactor of NLL region error reporting. Also includes some new documentation based on my discussion with @jseyfried on IRC.
r? @jseyfried
|
|
InternedString
|
|
|
|
Provide better names for builtin deriving-generated attributes
First attempt at fixing #49967
Not in love with any choices here, don't be shy if you aren't happy with anything :)
I've tested that this produces nicer names in documentation, and that it no longer has issues conflicting with constants with the same name. (I guess we _could_ make a test for that... unsure if that would be valuable)
In all cases I took the names from the methods as declared in the relevant trait.
In some cases I had to prepend the names with _ otherwise there were errors about un-used variables. I'm uneasy with the inconsistency... do they all need to be like that? Is there a way to generate an alternate impl or use a different name (`_`?) in the cases where the arguments are not used?
Lastly the gensym addition to Ident I implemented largely as suggested, but I want to point out it's a little circuitous (at least, as far as I understand it). `cx.ident_of(name)` is just `Ident::from_str`, so we create an Ident then another Ident from it. `Ident::with_empty_ctxt(Symbol::gensym(string))` may or may not be equivalent, I don't know if it's important to intern it _then_ gensym it. It seems like either we could use that, or if we do want a new method to make this convenient, it could be on Ident instead (`from_str_gensymed`?)
|
|
This is useful when trying to compute when something is lexically before
something else, but they aren't necessarily in the same SyntaxContext
|
|
... and reimplement proc_macro::Span::parent using it. This function turns out
to be useful in the compiler as well
|
|
|
|
Because it's faster than HashMap.
This change reduces the time taken for a few of the rustc-perf
benchmarks, mostly the small ones, by up to 5%.
|
|
Removed 'proc' from the reserved keywords list
Remove 'proc' from the reserved keywords list.
'proc' is a very useful identifier name for a lot of things. It's especially useful when dealing with processes, operating system internals, and kernel development.
|
|
|
|
|
|
Add ok-wrapping to catch blocks, per RFC
Updates the `catch{}` lowering to wrap the result in `Try::from_ok`.
r? @nikomatsakis
Fixes #41414
Fixes #43818
|
|
|
|
|
|
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!
|
|
|
|
|
|
|
|
Merge upstream changes
|
|
|
|
Holy cow that's a lot of `cfg(stage0)` removed and a lot of new stable language
features!
|
|
Closes #22181, #27779
|
|
|
|
Misc changes from my parallel rustc branch
r? @michaelwoerister
|
|
syntax: Make imports in AST closer to the source and cleanup their parsing
This is a continuation of https://github.com/rust-lang/rust/pull/45846 in some sense.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes #47311.
r? @nrc
|
|
Remove experimental -Zremap-path-prefix-from/to, and replace it with
the stabilized --remap-path-prefix=from=to variant.
This is an implementation for issue of #41555.
|
|
|
|
|
|
spans involving macro context Sometimes the parser attempts to synthesize spans from within a macro context with the span for the captured argument, leading to non-sensical spans with very bad output. Given that an incorrect span is worse than a partially incomplete span, when detecting this situation return only one of the spans without merging them. Fix #32072, #47778. CC #23480.
|
|
Sometimes the parser attempts to synthesize spans from within a macro
context with the span for the captured argument, leading to non-sensical
spans with very bad output. Given that an incorrect span is worse than
a partially incomplete span, when detecting this situation return only
one of the spans without mergin them.
|