| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Fix the start/end byte positions in the compiler JSON output
Track the changes made during normalization in the `SourceFile` and use this information to correct the `start_byte` and `end_byte` fields in the JSON output.
This should ensure the start/end byte fields can be used to index the original file, even if Rust normalized the source code for parsing purposes. Both CRLF to LF and BOM removal are handled with this one.
The rough plan was discussed with @matklad in rust-lang-nursery/rustfix#176 - although I ended up going with `u32` offset tracking so I wouldn't need to deal with `u32 + i32` arithmetics when applying the offset to the span byte positions.
Fixes #65029
|
|
This commit stabilizes RFC 2008 (#44109) by removing the feature gate.
Signed-off-by: David Wood <david@davidtw.co>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use these to create call-site spans for AST passes when needed.
|
|
|
|
|
|
Replace them with equivalents of `Span::{def_site,call_site}` from proc macro API.
The new API is much less error prone and doesn't rely on macros having default transparency.
|
|
Normalize newlines when loading files
Fixes #62865
|
|
For naming consistency with everything else in this area
|
|
It was introduced to avoid going through `hygiene_data`, but now it's read only once, when `ParseSess` is created, so going through a lock is ok.
|
|
The expansion info is not optional and should always exist
|
|
For consistency with `ExpnId::root`.
Also introduce a helper `Span::with_root_ctxt` for creating spans with `SyntaxContext::root()` context
|
|
|
|
|
|
On `format!()` arg count mismatch provide extra info
When positional width and precision formatting flags are present in a
formatting string that has an argument count mismatch, provide extra
information pointing at them making it easiser to understand where the
problem may lay:
```
error: 4 positional arguments in format string, but there are 3 arguments
--> $DIR/ifmt-bad-arg.rs:78:15
|
LL | println!("{} {:.*} {}", 1, 3.2, 4);
| ^^ ^^--^ ^^ --- this parameter corresponds to the precision flag
| |
| this precision flag adds an extra required argument at position 1, which is why there are 4 arguments expected
|
= note: positional arguments are zero-based
= note: for information about formatting flags, visit https://doc.rust-lang.org/std/fmt/index.html
error: 4 positional arguments in format string, but there are 3 arguments
--> $DIR/ifmt-bad-arg.rs:81:15
|
LL | println!("{} {:07$.*} {}", 1, 3.2, 4);
| ^^ ^^-----^ ^^ --- this parameter corresponds to the precision flag
| | |
| | this precision flag adds an extra required argument at position 1, which is why there are 4 arguments expected
| this width flag expects an `usize` argument at position 7, but there are 3 arguments
|
= note: positional arguments are zero-based
= note: for information about formatting flags, visit https://doc.rust-lang.org/std/fmt/index.html
error: invalid reference to positional argument 7 (there are 3 arguments)
--> $DIR/ifmt-bad-arg.rs:84:18
|
LL | println!("{} {:07$} {}", 1, 3.2, 4);
| ^^^--^
| |
| this width flag expects an `usize` argument at position 7, but there are 3 arguments
|
= note: positional arguments are zero-based
= note: for information about formatting flags, visit https://doc.rust-lang.org/std/fmt/index.html
```
Fix #49384.
|
|
|
|
|
|
|
|
rustbuild
Remove some random unnecessary lint `allow`s
|
|
|
|
|
|
|
|
The root expansion was missing one.
Expansions created for "derive containers" (see one of the next commits for the description) also didn't get expansion info.
|
|
Use variant names rather than descriptions for identifying desugarings in `#[rustc_on_unimplemented]`.
Both are highly unstable, but variant name is at least a single identifier.
|
|
Orthogonality and reuse are good.
|
|
ExpnInfo/MacroBacktrace/DiagnosticSpanMacroExpansion
We have to deal with dummy spans anyway
Remove def-site span from expander interfaces.
It's not used by the expansion infra, only by specific expanders, which can keep it themselves if they want it.
|
|
More consistent with other naming:
ExpnFormat -> ExpnKind
ExpnKind::name -> ExpnKind::descr
DesugaringKind::name -> DesugaringKind::descr
Shorter, no tautology:
CompilerDesugaring -> Desugaring
CompilerDesugaringKind -> DesugaringKind
|
|
|
|
This is an extremely marginal error, so the cost of properly threading
`Handler` everywhere just not seemed justified. However, it's useful
to panic when we create a file, and not when we slice strings with
overflown indexes somewhere in the guts of the compiler.
For this reason, while we provide safe `try_new_source_file`, we don't
change the existing public interface and just panic more or less
cleanly.
|
|
Use Symbol, Span in libfmt_macros
I'm not super happy with this, personally, but I think it might be a decent start -- happy to take suggestions as to how to expand this or change things further.
r? @estebank
Fixes #60795
|
|
|
|
This should be used when trying to get at subsets of a larger span,
especially when the larger span is not available in the code attempting
to work with those subsets (especially common in the fmt_macros crate).
This is usually a good replacement for (BytePos, BytePos) and (usize,
usize) tuples.
This commit also removes from_inner_byte_pos, since it took usize
arguments, which is error prone.
|
|
|
|
These combine two `HygieneData::with` calls into one.
|
|
|
|
It reduces two `hygiene_data` accesses to one on some hot paths.
|
|
|
|
And also the equality between `Path` and strings, because `Path` is made
up of `Symbol`s.
|
|
|
|
Because it's going to be used a lot.
|
|
|
|
|
|
It is now exactly equivalent to lookup_char_pos.
|
|
- libarena
- librustc_allocator
- librustc_borrowck
- librustc_codegen_ssa
- librustc_codegen_utils
- librustc_driver
- librustc_errors
- librustc_incremental
- librustc_metadata
- librustc_passes
- librustc_privacy
- librustc_resolve
- librustc_save_analysis
- librustc_target
- librustc_traits
- libsyntax
- libsyntax_ext
- libsyntax_pos
|
