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
Remove `InternedString`
This PR removes `InternedString` by converting all occurrences to `Symbol`. There are a handful of places that need to use the symbol chars instead of the symbol index, e.g. for stable sorting; local conversions `LocalInternedString` is used in those places.
r? @eddyb
It's a full conversion, except in `DefKey::compute_stable_hash()` where
a `Symbol` now is converted to an `InternedString` before being hashed.
This was necessary to avoid test failures.
Avoid injecting sanitizer runtimes into staticlibs (#64629).
This fixes the remaining issue in `creader.rs` and also fixes the expected test failure. I have explicitly turned the `$(CC)` call into a negative check with the `!` to ensure that this command is really failing (if it is not, then either the runtime is attached to the lib or the lib has not been instrumented and both would be an error).
I've also borrowed `program.rs` and the additional `rustc` invocation from @tmiasko 's PR since he pointed out that using `-fsanitize=address` with `$(CC)` for linking could fail if the sanitizer runtimes on the system are incompatible.
With this toolchain I was able to compile Firefox locally without any linker errors. I am still seeing races with Rust in TSan but I assume that is because I did not build with `-Z build-std`.
rustc: arena-allocate the slice in `ty::GenericsPredicate`, not the whole struct.
While rebasing #59789 I noticed we can do this now. However, it doesn't help much without changing `inferred_outlives_of` to the same type, which I might try next.
Rollup of 8 pull requests
Successful merges:
- #65237 (Move debug_map assertions after check for err)
- #65316 (make File::try_clone produce non-inheritable handles on Windows)
- #65319 (InterpCx: make memory field public)
- #65461 (Don't recommend ONCE_INIT in std::sync::Once)
- #65465 (Move syntax::ext to a syntax_expand and refactor some attribute logic)
- #65475 (add example for type_name)
- #65478 (fmt::Write is about string slices, not byte slices)
- #65486 (doc: fix typo in OsStrExt and OsStringExt)
Failed merges:
r? @ghost
self-profiling: Add events for metadata loading (plus a small dep-tracking optimization)
This PR
- adds self-profiling events related to loading things from crate metadata
- makes the compiler cache the `DepNodeIndex` of upstream crates, so that they don't have to be looked up over and over.
The commits are best reviewed in isolation.
Self-profiling tracking issue: https://github.com/rust-lang/rust/issues/58967
r? @Mark-Simulacrum
cc @wesleywiser
Improve message when attempting to instantiate tuple structs with private fields
Fixes#58017, fixes#39703.
```
error[E0603]: tuple struct `Error` is private
--> main.rs:22:16
|
2 | pub struct Error(usize, pub usize, usize);
| ----- ----- field is private
| |
| field is private
...
22 | let x = a::Error(3, 1, 2);
| ^^^^^
|
= note: a tuple struct constructor is private if any of its fields is private
```
