| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This is only really useful in debug messages, so I've switched to
calling `span_to_string` in any place that causes a `Span` to end up in
user-visible output.
|
|
Rename all remaining compiler crates to use the `rustc_foo` pattern
libarena -> librustc_arena
libfmt_macros -> librustc_parse_format
libgraphviz -> librustc_graphviz
libserialize -> librustc_serialize
Closes https://github.com/rust-lang/rust/issues/71177 in particular.
|
|
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.
|
|
|
|
|
|
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.
|
|
r=eddyb
Track devirtualized filenames
Split payload of FileName::Real to track both real and virtualized paths.
(Such splits arise from metadata refs into libstd; the virtualized paths look like `/rustc/1.45.0/src/libstd/io/cursor.rs` rather than `/Users/felixklock/Dev/Mozilla/rust.git/src/libstd/io/cursor.rs`)
This way, we can emit the virtual name into things like the like the StableSourceFileId (as was done back before PR #70642) that ends up in incremental build artifacts, while still using the devirtualized file path when we want to access the file.
Fix #70924
|
|
Improve inline asm error diagnostics
Previously we were just using the raw LLVM error output (with line, caret, etc) as the diagnostic message, which ends up looking rather out of place with our existing diagnostics.
The new diagnostics properly format the diagnostics and also take advantage of LLVM's per-line `srcloc` attribute to map an error in inline assembly directly to the relevant line of source code.
Incidentally also fixes #71639 by disabling `srcloc` metadata during LTO builds since we don't know what crate it might have come from. We can only resolve `srcloc`s from the currently crate since it indexes into the source map for the current crate.
Fixes #72664
Fixes #71639
r? @petrochenkov
### Old style
```rust
#![feature(llvm_asm)]
fn main() {
unsafe {
let _x: i32;
llvm_asm!(
"mov $0, $1
invalid_instruction $0, $1
mov $0, $1"
: "=&r" (_x)
: "r" (0)
:: "intel"
);
}
}
```
```
error: <inline asm>:3:14: error: invalid instruction mnemonic 'invalid_instruction'
invalid_instruction ecx, eax
^~~~~~~~~~~~~~~~~~~
--> src/main.rs:6:9
|
6 | / llvm_asm!(
7 | | "mov $0, $1
8 | | invalid_instruction $0, $1
9 | | mov $0, $1"
... |
12 | | :: "intel"
13 | | );
| |__________^
```
### New style
```rust
#![feature(asm)]
fn main() {
unsafe {
asm!(
"mov {0}, {1}
invalid_instruction {0}, {1}
mov {0}, {1}",
out(reg) _,
in(reg) 0i64,
);
}
}
```
```
error: invalid instruction mnemonic 'invalid_instruction'
--> test.rs:7:14
|
7 | invalid_instruction {0}, {1}
| ^
|
note: instantiated into assembly here
--> <inline asm>:3:14
|
3 | invalid_instruction rax, rcx
| ^^^^^^^^^^^^^^^^^^^
```
|
|
|
|
encoded build artifacts.
Fix #70924.
|
|
Such splits arise from metadata refs into libstd.
This way, we can (in a follow on commit) continue to emit the virtual name into
things like the like the StableSourceFileId that ends up in incremetnal build
artifacts, while still using the devirtualized file path when we want to access
the file.
Note that this commit is intended to be a refactoring; the actual fix to the bug
in question is in a follow-on commit.
|
|
(and I want to discourage further use of it if possible.)
|
|
r=nikomatsakis
Implement RFC 2585: unsafe blocks in unsafe fn
Tracking issue: #71668
r? @RalfJung cc @nikomatsakis
|
|
|
|
|
|
Miri's pointer_offset_inbounds implementation has been moved into
librustc_mir as ptr_offset_inbounds (to avoid breaking miri on a
nightly update). The comments have been slightly reworked to better
match `offset`'s external documentation about what causes UB.
The intrinsic implementations are taken directly from miri.
Signed-off-by: Joe Richey <joerichey@google.com>
|
|
We store store the `DefId` directly in `ExpnData`. This will allow us to
serialize `ExpnData` in PR #72121 without needing to manage a side
table.
|
|
Introduce function attribute corresponding to the `const`/`pure`
attributes supported by GCC, clang and other compilers.
Based on the work of gnzlbg <gonzalobg88@gmail.com>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Implement RFC 2523, `#[cfg(version(..))]`
Hi! This is my first contribution to rust, I hope I didn't miss anything. I tried to implement this feature so that `#[cfg(version(1.44.0))]` works but the parser was printing an error that I wasn't sure how to fix so I just opted for implementing `#[cfg(version("1.44.0"))]` (note the quotes).
Tracking issue: #64796
|
|
|
|
fix rustdoc warnings
|
|
|
|
|
|
Remove unused abs_path method from rustc_span::source_map::FileLoader
|
|
Bump bootstrap compiler
This bumps the bootstrap compiler and the rustfmt that x.py fmt uses.
|
|
|
|
|
|
|
|
Remove a stack frame from .await calls
The stack frames when `.await`ing one async fn from another currently look like this:
```
12: foo::b::{{closure}}
at src/main.rs:2
13: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:66
14: core::future::poll_with_context
at /home/sfackler/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore/future/mod.rs:84
15: foo::a::{{closure}}
at src/main.rs:6
```
Since the move away from using TLS to pass the Context around, it's now easy to remove frame 14 by removing poll_with_context in favor of calling Future::poll directly. This still leaves the `GenFuture` frame, but that seems significantly harder to deal with.
It also improves diagnostics a bit since they no longer talk about the private poll_with_context function.
|
|
|
|
Add some basic docs to `sym` and `kw` modules
I was looking into improving some Clippy documentation but was missing a
place that explains the `kw` and `sym` modules from rustc.
This adds some very basic usage documentation to these modules.
|
|
Normalize source when loading external foreign source into SourceMap
The compiler normalizes source when reading files initially (removes BOMs, etc), but not when loading external sources.
This leads to the external source matching according to the `src_hash`, but differing internally because it was not normalized.
Fixes #70874.
|
|
I was looking into improving some Clippy documentation but was missing a
place that explains the `kw` and `sym` modules from rustc.
|
|
The compiler normalizes source when reading files initially (removes BOMs, etc), but not when loading external sources.
Fixes #70874 by normalizing when loading external sources too. Adds a test to verify normalization.
|
|
r=eddyb
rustc_middle: return `LocalDefId` where possible in hir::map module
This changes the return type of the following functions to return a `LocalDefId` instead of a `DefId`:
* opt_local_def_id_from_node_id
* opt_local_def_id
* body_owner_def_id
* local_def_id_from_node_id
* get_parent_id
This is another step in the right direction for #70853
This pull request will be followed by another (substantial one) which changes the return type of `local_def_id` function but this change being more invasive, we might want to wait for #70956 or #70961 (or some other form it) to land first.
|
|
|
|
|
|
|
|
|
|
* Adds either an MD5 or SHA1 hash to the debug info.
* Adds new unstable option `-Z src-hash-algorithm` to control the hashing algorithm.
|
|
|
