Currently, the `Debug` impl for `proc_macro::Span` just prints out
the byte range. This can make debugging proc macros (either as a crate
author or as a compiler developer) very frustrating, since neither the
actual filename nor the `SyntaxContext` is displayed.
This commit adds a perma-unstable flag `-Z span-debug`. When enabled,
the `Debug` impl for `proc_macro::Span` simply forwards directly to
`rustc_span::Span`. Once #72618 is merged, this will start displaying
actual line numbers.
While `Debug` impls are not subject to Rust's normal stability
guarnatees, we probably shouldn't expose any additional information on
stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise,
we would be providing a 'backdoor' way to access information that's
supposed be behind unstable APIs.
Add myself to mailmap
Now that I have (accidentally) made contributions using two separate email addresses, I've added the rest of the addresses I typical use.
Add more assert to Vec with_capacity docs
Show assertion on len too to show them how adding new items will affect both the
length and capacity, before and after.
We were computing a merge-base between the remote beta and master
branches, but this was giving incorrect answers for the first beta if
the remote hadn't been pushed yet. For instance, `1.45.0-beta.3359`
corresponds to the number of merges since the 1.44 beta, but we really
want just `.1` for the sole 1.45 beta promotion merge.
We don't really need to query the remote beta at all -- `master..HEAD`
suffices if we assume that we're on the intended beta branch already.
Previously errors were sorted by Symbol index instead of the string. The
indexes are not the same between architectures because Symbols for
architecture extensions (e.g. x86 AVX or RISC-V d) are interned before
the source file is parsed. RISC-V's naming of extensions after single
letters led to it having errors sorted differently for test cases using
single letter variable names. Instead sort the errors by the Symbol
string so that it is stable across architectures.
save_analysis: work on HIR tree instead of AST
In order to reduce the uses of `NodeId`s in the compiler, `save_analysis` crate has been reworked to operate on the HIR tree instead of the AST.
cc #50928
LLVM 10 includes a009a60a917bc30940422bcef73f8270566d78db which will
print value numbers for unnamed func args.
Update these tests to be in line with the referenced clang tests.
Bump libc dependency to latest version (0.2.71)
Hello,
Just a quick version bump PR. The rust-psp group had some changes merged to libc recently but they haven't made it into the compiler. We're looking to remove our forked version from our Xargo.toml. Thanks.
Add Camelid per request
Email from @camelid:
> HI there,
>
> I’m a new contributor and I just looked at Rust Thanks and noticed that my contributions are listed under two different capitalizations of my name: “Camelid" and “camelid". Could you make them both “Camelid"?
>
> Thanks!
>
> Camelid
Make `SourceMap` available for early debug-printing of `Span`s
Normally, we debug-print `Spans` using the `SourceMap` retrieved from
the global `TyCtxt`. However, we fall back to printing out the `Span`'s
raw fields (instead of a file and line number) when we try to print a
`Span` before a `TyCtxt` is available. This makes debugging early phases
of the compile, such as parsing, much more difficult.
This commit stores a `SourceMap` in `rustc_span::GlOBALS` as a fallback.
When a `TyCtxt` is not available, we try to retrieve one from `GLOBALS`
- only if this is not available do we fall back to the raw field output.
I'm not sure how to write a test for this - however, this can be
verified locally by setting `RUSTC_LOG="rustc_parse=debug"`, and
verifying that the output contains filenames and line numbers.
Email from @camelid:
> HI there,
>
> I’m a new contributor and I just looked at Rust Thanks and noticed that my contributions are listed under two different capitalizations of my name: “Camelid" and “camelid". Could you make them both “Camelid"?
>
> Thanks!
>
> Camelid
