about summary refs log tree commit diff
path: root/compiler/rustc_span/src/lib.rs
AgeCommit message (Collapse)AuthorLines
2024-11-12Auto merge of #132282 - Noratrieb:it-is-the-end-of-serial, r=cjgillotbors-8/+0
Delete the `cfg(not(parallel))` serial compiler Since it's inception a long time ago, the parallel compiler and its cfgs have been a maintenance burden. This was a necessary evil the allow iteration while not degrading performance because of synchronization overhead. But this time is over. Thanks to the amazing work by the parallel working group (and the dyn sync crimes), the parallel compiler has now been fast enough to be shipped by default in nightly for quite a while now. Stable and beta have still been on the serial compiler, because they can't use `-Zthreads` anyways. But this is quite suboptimal: - the maintenance burden still sucks - we're not testing the serial compiler in nightly Because of these reasons, it's time to end it. The serial compiler has served us well in the years since it was split from the parallel one, but it's over now. Let the knight slay one head of the two-headed dragon! #113349 Note that the default is still 1 thread, as more than 1 thread is still fairly broken. cc `@onur-ozkan` to see if i did the bootstrap field removal correctly, `@SparrowLii` on the sync parts
2024-11-12Delete the `cfg(not(parallel))` serial compilerNoratrieb-8/+0
Since it's inception a long time ago, the parallel compiler and its cfgs have been a maintenance burden. This was a necessary evil the allow iteration while not degrading performance because of synchronization overhead. But this time is over. Thanks to the amazing work by the parallel working group (and the dyn sync crimes), the parallel compiler has now been fast enough to be shipped by default in nightly for quite a while now. Stable and beta have still been on the serial compiler, because they can't use `-Zthreads` anyways. But this is quite suboptimal: - the maintenance burden still sucks - we're not testing the serial compiler in nightly Because of these reasons, it's time to end it. The serial compiler has served us well in the years since it was split from the parallel one, but it's over now. Let the knight slay one head of the two-headed dragon!
2024-11-10Address review commentsLeón Orell Valerian Liehr-0/+4
2024-10-07Avoid another `&Lrc<..>` in a return value.Nicholas Nethercote-1/+1
2024-10-01disregard what we believe is supported in cargo for hash typeJacob Kiesel-9/+0
2024-10-01add unstable support for outputting file checksums for use in cargoJacob Kiesel-7/+139
2024-09-22Reformat using the new identifier sorting from rustfmtMichael Goulet-5/+5
2024-09-03Auto merge of #129777 - nnethercote:unreachable_pub-4, r=Urgaubors-0/+1
Add `unreachable_pub`, round 4 A follow-up to #129732. r? `@Urgau`
2024-09-03Add `warn(unreachable_pub)` to `rustc_span`.Nicholas Nethercote-0/+1
2024-09-02chore: Fix typos in 'compiler' (batch 2)Alexander Cyon-2/+2
2024-08-27compiler: Remove feature(new_uninit)Jubilee Young-1/+0
2024-08-06Skip locking span interner for some syntax context checksAlex Macleod-6/+0
2024-07-29Reformat `use` declarations.Nicholas Nethercote-9/+9
The previous commit updated `rustfmt.toml` appropriately. This commit is the outcome of running `x fmt --all` with the new formatting options.
2024-07-25Auto merge of #127042 - GrigorenkoPV:derivative, r=compiler-errorsbors-4/+5
Switch from `derivative` to `derive-where` This is a part of the effort to get rid of `syn 1.*` in compiler's dependencies: #109302 Derivative has not been maintained in nearly 3 years[^1]. It also depends on `syn 1.*`. This PR replaces `derivative` with `derive-where`[^2], a not dead alternative, which uses `syn 2.*`. A couple of `Debug` formats have changed around the skipped fields[^3], but I doubt this is an issue. [^1]: https://github.com/mcarton/rust-derivative/issues/117 [^2]: https://lib.rs/crates/derive-where [^3]: See the changes in `tests/ui`
2024-07-18Make unicode text flow control chars visible as �Esteban Küber-1/+2
We already point these out quite aggressively, telling people not to use them, but would normally be rendered as nothing. Having them visible will make it easier for people to actually deal with them. ``` error: unicode codepoint changing visible direction of text present in literal --> $DIR/unicode-control-codepoints.rs:26:22 | LL | println!("{:?}", '�'); | ^-^ | || | |'\u{202e}' | this literal contains an invisible unicode text flow control codepoint | = note: these kind of unicode codepoints change the way text flows on applications that support them, but can cause confusion because they change the order of characters on the screen = help: if their presence wasn't intentional, you can remove them help: if you want to keep them but make them visible in your source code, you can escape them | LL | println!("{:?}", '\u{202e}'); | ~~~~~~~~ ``` vs the previous ``` error: unicode codepoint changing visible direction of text present in literal --> $DIR/unicode-control-codepoints.rs:26:22 | LL | println!("{:?}", ''); | ^- | || | |'\u{202e}' | this literal contains an invisible unicode text flow control codepoint | = note: these kind of unicode codepoints change the way text flows on applications that support them, but can cause confusion because they change the order of characters on the screen = help: if their presence wasn't intentional, you can remove them help: if you want to keep them but make them visible in your source code, you can escape them | LL | println!("{:?}", '\u{202e}'); | ~~~~~~~~ ```
2024-07-18Be more accurate about calculating `display_col` from a `BytePos`Esteban Küber-100/+33
No longer track "zero-width" chars in `SourceMap`, read directly from the line when calculating the `display_col` of a `BytePos`. Move `char_width` to `rustc_span` and use it from the emitter. This change allows the following to properly align in terminals (depending on the font, the replaced control codepoints are rendered as 1 or 2 width, on my terminal they are rendered as 1, on VSCode text they are rendered as 2): ``` error: this file contains an unclosed delimiter --> $DIR/issue-68629.rs:5:17 | LL | ␜␟ts␀![{i | -- unclosed delimiter | | | unclosed delimiter LL | ␀␀ fn rݻoa>rݻm | ^ ```
2024-07-12rustc_span: derivative -> derive-wherePavel Grigorenko-4/+5
2024-06-21Auto merge of #123165 - oli-obk:no_ord_def_id3, r=cjgillotbors-31/+8
Stop sorting `Span`s' `SyntaxContext`, as that is incompatible with incremental work towards https://github.com/rust-lang/rust/issues/90317 Luckily no one actually needed these to be sorted, so it didn't even affect diagnostics. I'm guessing they'd have been sorted by creation time anyway, so it wouldn't really have mattered. r? `@cjgillot`
2024-06-20rustc_span: Optimize span parent get/set methodsVadim Petrochenkov-9/+2
2024-06-16Auto merge of #126543 - petrochenkov:upctxt4, r=cjgillotbors-15/+25
rustc_span: Optimize more hygiene operations using `Span::map_ctxt` I missed these in https://github.com/rust-lang/rust/pull/125017.
2024-06-16rustc_span: Minor improvementsVadim Petrochenkov-2/+2
Introduce `{IndexNewtype,SyntaxContext}::from_u16` for convenience because small indices are sometimes encoded as `u16`. Use `SpanData::span` instead of `Span::new` where appropriate. Add a clarifying comment about decoding span parents.
2024-06-16rustc_span: Optimize more hygiene operations using `Span::map_ctxt`Vadim Petrochenkov-15/+25
2024-06-13rustc_span: By-value interface for ctxt updateVadim Petrochenkov-13/+9
2024-06-13rustc_span: Add conveniences for working with span formatsVadim Petrochenkov-0/+1
2024-06-10rustc_span: Optimize syntax context updates in spansVadim Petrochenkov-12/+13
2024-06-04Add `Span::trim_end`Zalathar-0/+7
This is the counterpart of `Span::trim_start`.
2024-05-22Remove `#[macro_use]` extern crate tracing` from `rustc_span`.Nicholas Nethercote-3/+1
Because explicit macro imports are better than implicit macro imports.
2024-05-22Add a useful comment.Nicholas Nethercote-0/+3
For something that wasn't obvious to me.
2024-04-29Remove `extern crate rustc_macros` from numerous crates.Nicholas Nethercote-4/+1
2024-04-19Stop sorting `Span`s' `SyntaxContext`, as that is incompatible with incrementalOli Scherer-31/+8
2024-04-16Construct `SourceMap` at the same time as `SessionGlobals`.Nicholas Nethercote-35/+18
Currently `SourceMap` is constructed slightly later than `SessionGlobals`, and inserted. This commit changes things so they are done at the same time. Benefits: - `SessionGlobals::source_map` changes from `Lock<Option<Lrc<SourceMap>>>` to `Option<Lrc<SourceMap>>`. It's still optional, but mutability isn't required because it's initialized at construction. - `set_source_map` is removed, simplifying `run_compiler`, which is good because that's a critical function and it's nice to make it simpler. This requires moving things around a bit, so the necessary inputs are available when `SessionGlobals` is created, in particular the `loader` and `hash_kind`, which are no longer computed by `build_session`. These inputs are captured by the new `SourceMapInputs` type, which is threaded through various places.
2024-04-10typeck: fix `?` operator suggestion span许杰友 Jieyou Xu (Joe)-0/+39
2024-03-28Replace Session should_remap_filepaths with filename_display_preferenceUrgau-0/+12
2024-03-27Helper function for resolve_pathKornel-0/+11
2024-02-18macro_rules: Preserve all metavariable spans in a global side tableVadim Petrochenkov-14/+59
2024-02-11Rollup merge of #120272 - ↵Matthias Krüger-0/+7
long-long-float:suppress-suggestions-in-derive-macro, r=oli-obk Suppress suggestions in derive macro close #118809 I suppress warnings inside derive macros. For example, the compiler emits following error by a program described in https://github.com/rust-lang/rust/issues/118809#issuecomment-1852256687 with a suggestion that indicates invalid syntax. ``` error[E0308]: `?` operator has incompatible types --> src/main.rs:3:17 | 3 | #[derive(Debug, Deserialize)] | ^^^^^^^^^^^ expected `u32`, found `u64` | = note: `?` operator cannot convert from `u64` to `u32` = note: this error originates in the derive macro `Deserialize` (in Nightly builds, run with -Z macro-backtrace for more info) help: you can convert a `u64` to a `u32` and panic if the converted value doesn't fit | 3 | #[derive(Debug, Deserialize.try_into().unwrap())] | ++++++++++++++++++++ For more information about this error, try `rustc --explain E0308`. error: could not compile `serde_test` (bin "serde_test") due to 2 previous errors ``` In this PR, suggestions to cast are suppressed. ``` error[E0308]: `?` operator has incompatible types --> src/main.rs:3:17 | 3 | #[derive(Debug, Deserialize)] | ^^^^^^^^^^^ expected `u32`, found `u64` | = note: `?` operator cannot convert from `u64` to `u32` = note: this error originates in the derive macro `Deserialize` (in Nightly builds, run with -Z macro-backtrace for more info) For more information about this error, try `rustc --explain E0308`. error: could not compile `serde_test` (bin "serde_test") due to 2 previous errors ```
2024-02-09Rollup merge of #120693 - nnethercote:invert-diagnostic-lints, r=davidtwcoMatthias Krüger-2/+0
Invert diagnostic lints. That is, change `diagnostic_outside_of_impl` and `untranslatable_diagnostic` from `allow` to `deny`, because more than half of the compiler has been converted to use translated diagnostics. This commit removes more `deny` attributes than it adds `allow` attributes, which proves that this change is warranted. r? ````@davidtwco````
2024-02-09Check with overlaps_or_adjacentlong-long-float-0/+7
2024-02-07Rename `unchecked_claim_error_was_emitted` as `unchecked_error_guaranteed`.Nicholas Nethercote-1/+1
It's more to-the-point.
2024-02-07Tighten up `ErrorGuaranteed` handling.Nicholas Nethercote-3/+2
- In `emit_producing_error_guaranteed`, only allow `Level::Error`. - In `emit_diagnostic`, only produce `ErrorGuaranteed` for `Level` and `DelayedBug`. (Not `Bug` or `Fatal`. They don't need it, because the relevant `emit` methods abort.) - Add/update various comments.
2024-02-06Invert diagnostic lints.Nicholas Nethercote-2/+0
That is, change `diagnostic_outside_of_impl` and `untranslatable_diagnostic` from `allow` to `deny`, because more than half of the compiler has be converted to use translated diagnostics. This commit removes more `deny` attributes than it adds `allow` attributes, which proves that this change is warranted.
2024-01-28normalize_newlines(): fix incorrect commentMatthew Woodcraft-1/+1
2024-01-09Remove more needless leb128 coding for enum variantsMark Rousskov-11/+12
This removes emit_enum_variant and the emit_usize calls that resulted in. In libcore this eliminates 17% of leb128, taking us from 8964488 to 7383842 leb128's serialized.
2024-01-09Rollup merge of #118903 - azhogin:azhogin/skip_second_stmt_debuginfo.rs, ↵Matthias Krüger-7/+0
r=petrochenkov Improved support of collapse_debuginfo attribute for macros. Added walk_chain_collapsed function to consider collapse_debuginfo attribute in parent macros in call chain. Fixed collapse_debuginfo attribute processing for cranelift (there was if/else branches error swap). cc https://github.com/rust-lang/rust/issues/100758
2024-01-08Improved support of collapse_debuginfo attribute for macros.Andrew Zhogin-7/+0
2024-01-06Auto merge of #119662 - matthiaskrgr:rollup-ehofh5n, r=matthiaskrgrbors-49/+47
Rollup of 9 pull requests Successful merges: - #118194 (rustdoc: search for tuples and unit by type with `()`) - #118781 (merge core_panic feature into panic_internals) - #119486 (pass allow-{dirty,staged} to clippy) - #119591 (rustc_mir_transform: Make DestinationPropagation stable for queries) - #119595 (Fixed ambiguity in hint.rs) - #119624 (rustc_span: More consistent span combination operations) - #119653 (compiler: update Fuchsia sanitizer support.) - #119655 (Remove ignore-stage1 that was added when changing error count msg) - #119661 (Strip lld-wrapper binaries) r? `@ghost` `@rustbot` modify labels: rollup
2024-01-06Rollup merge of #119624 - petrochenkov:dialoc4, r=compiler-errorsMatthias Krüger-49/+47
rustc_span: More consistent span combination operations Also add more tests for using `tt` in addition to `ident`, and some other minor tweaks, see individual commits. This is a part of https://github.com/rust-lang/rust/pull/119412 that doesn't yet add side tables for metavariable spans.
2024-01-06Auto merge of #119531 - petrochenkov:cmpctxt, r=cjgillotbors-20/+16
rustc_span: Optimize syntax context comparisons Including comparisons with root context. - `eq_ctxt` doesn't require retrieving full `SpanData`, or taking the span interner lock twice. - Checking `SyntaxContext` for "rootness" is cheaper than extracting a full outer `ExpnData` for it and checking *it* for rootness. The internal lint for `eq_ctxt` is also tweaked to detect `a.ctxt() != b.ctxt()` in addition to `a.ctxt() == b.ctxt()`.
2024-01-06rustc_span: Optimize syntax context comparisonsVadim Petrochenkov-20/+16
Including comparisons with root context
2024-01-05rustc_span: More consistent span combination operationsVadim Petrochenkov-49/+47