about summary refs log tree commit diff
path: root/compiler/rustc_span/src
AgeCommit message (Collapse)AuthorLines
2021-10-11Add enum_intrinsics_non_enums lintFlying-Toast-0/+1
2021-10-08Add feature gate to non_exhaustive_omitted_patterns lintDevin Ragotzy-0/+1
Actually add the feature to the lints ui test Add tracking issue to the feature declaration Rename feature gate to non_exhaustive_omitted_patterns_lint Add more omitted_patterns lint feature gate
2021-10-07Rollup merge of #89622 - m-ou-se:debug-assert-2021, r=estebankJubilee-0/+1
Use correct edition for panic in [debug_]assert!(). See https://github.com/rust-lang/rust/issues/88638#issuecomment-915472783
2021-10-07Use correct edition for panic in [debug_]assert!() etc.Mara Bos-0/+1
2021-10-05Allow adding a set of cfg's to hide from being implicitly doc(cfg)'dWim Looman-0/+2
By adding #![doc(cfg_hide(foobar))] to the crate attributes the cfg #[cfg(foobar)] (and _only_ that _exact_ cfg) will not be implicitly treated as a doc(cfg) to render a message in the documentation.
2021-10-03Auto merge of #88175 - camsteffen:let-desugar-span, r=Manishearthbors-0/+2
Add expansion to while desugar spans In the same vein as #88163, this reverts a change in Clippy behavior as a result of #80357 (and reverts some `#[allow]`s): This changes `clippy::blocks_in_if_conditions` to not fire on `while` loops. Though we might actually want Clippy to lint those cases, we should introduce the change purposefully, with tests, and possibly under a different lint name. The actual change here is to add a desugaring expansion to the spans when lowering a `while` loop. r? `@Manishearth`
2021-10-02Make diangostic item names consistentCameron Steffen-15/+8
2021-10-02Add desugaring mark to while loopCameron Steffen-0/+2
2021-10-02rustc_span: Make hygiene debug printing reproducibleVadim Petrochenkov-1/+4
2021-09-24Rollup merge of #89072 - bjorn3:less_symbol_as_str, r=michaelwoeristerJubilee-5/+1
Avoid a couple of Symbol::as_str calls in cg_llvm This should improve performance a tiny bit. Also remove `Symbol::len` and make `SymbolIndex` private.
2021-09-23Auto merge of #87064 - Aaron1011:new-closure-track-caller, r=estebankbors-0/+1
Support `#[track_caller]` on closures and generators ## Lang team summary This PR adds support for placing the `#[track_caller]` attribute on closure and generator expressions. This attribute's addition behaves identically (from a users perspective) to the attribute being placed on the method in impl Fn/FnOnce/FnMut for ... generated by compiler. The attribute is currently "double" feature gated -- both `stmt_expr_attributes` (preexisting) and `closure_track_caller` (newly added) must be enabled in order to place these attributes on closures. As the Fn* traits lack a `#[track_caller]` attribute in their definition, caller information does not propagate when invoking closures through dyn Fn*. There is no limitation that this PR adds in supporting this; it can be added in the future. # Implementation details This is implemented in the same way as for functions - an extra location argument is appended to the end of the ABI. For closures, this argument is *not* part of the 'tupled' argument storing the parameters - the final closure argument for `#[track_caller]` closures is no longer a tuple. For direct (monomorphized) calls, the necessary support was already implemented - we just needeed to adjust some assertions around checking the ABI and argument count to take closures into account. For calls through a trait object, more work was needed. When creating a `ReifyShim`, we need to create a shim for the trait method (e.g. `FnOnce::call_mut`) - unlike normal functions, closures are never invoked directly, and always go through a trait method. Additional handling was needed for `InstanceDef::ClosureOnceShim`. In order to pass location information throgh a direct (monomorphized) call to `FnOnce::call_once` on an `FnMut` closure, we need to make `ClosureOnceShim` aware of `#[tracked_caller]`. A new field `track_caller` is added to `ClosureOnceShim` - this is used by `InstanceDef::requires_caller` location, allowing codegen to pass through the extra location argument. Since `ClosureOnceShim.track_caller` is only used by codegen, we end up generating two identical MIR shims - one for `track_caller == true`, and one for `track_caller == false`. However, these two shims are used by the entire crate (i.e. it's two shims total, not two shims per unique closure), so this shouldn't a big deal.
2021-09-23Auto merge of #89139 - camsteffen:write-perf, r=Mark-Simulacrumbors-0/+1
Use ZST for fmt unsafety as suggested here - https://github.com/rust-lang/rust/pull/83302#issuecomment-923529151.
2021-09-22Support `#[track_caller]` on closures and generatorsAaron Hill-0/+1
This PR allows applying a `#[track_caller]` attribute to a closure/generator expression. The attribute as interpreted as applying to the compiler-generated implementation of the corresponding trait method (`FnOnce::call_once`, `FnMut::call_mut`, `Fn::call`, or `Generator::resume`). This feature does not have its own feature gate - however, it requires `#![feature(stmt_expr_attributes)]` in order to actually apply an attribute to a closure or generator. This is implemented in the same way as for functions - an extra location argument is appended to the end of the ABI. For closures, this argument is *not* part of the 'tupled' argument storing the parameters - the final closure argument for `#[track_caller]` closures is no longer a tuple. For direct (monomorphized) calls, the necessary support was already implemented - we just needeed to adjust some assertions around checking the ABI and argument count to take closures into account. For calls through a trait object, more work was needed. When creating a `ReifyShim`, we need to create a shim for the trait method (e.g. `FnOnce::call_mut`) - unlike normal functions, closures are never invoked directly, and always go through a trait method. Additional handling was needed for `InstanceDef::ClosureOnceShim`. In order to pass location information throgh a direct (monomorphized) call to `FnOnce::call_once` on an `FnMut` closure, we need to make `ClosureOnceShim` aware of `#[tracked_caller]`. A new field `track_caller` is added to `ClosureOnceShim` - this is used by `InstanceDef::requires_caller` location, allowing codegen to pass through the extra location argument. Since `ClosureOnceShim.track_caller` is only used by codegen, we end up generating two identical MIR shims - one for `track_caller == true`, and one for `track_caller == false`. However, these two shims are used by the entire crate (i.e. it's two shims total, not two shims per unique closure), so this shouldn't a big deal.
2021-09-22Rollup merge of #89046 - oli-obk:fix_oflo, r=estebankthe8472-8/+29
"Fix" an overflow in byte position math r? `@estebank` help! I fixed the ICE only to brick the diagnostic. I mean, it was wrong previously (using an already expanded macro span), but it is really bad now XD
2021-09-22Make SymbolIndex privatebjorn3-1/+1
2021-09-22Remove Symbol::lenbjorn3-4/+0
It is used exactly once and can be replaced with the equally fast .as_str().len()
2021-09-22Auto merge of #88865 - guswynn:must_not_suspend, r=oli-obkbors-0/+1
Implement `#[must_not_suspend]` implements #83310 Some notes on the impl: 1. The code that searches for the attribute on the ADT is basically copied from the `must_use` lint. It's not shared, as the logic did diverge 2. The RFC does specify that the attribute can be placed on fn's (and fn-like objects), like `must_use`. I think this is a direct copy from the `must_use` reference definition. This implementation does NOT support this, as I felt that ADT's (+ `impl Trait` + `dyn Trait`) cover the usecase's people actually want on the RFC, and adding an imp for the fn call case would be significantly harder. The `must_use` impl can do a single check at fn call stmt time, but `must_not_suspend` would need to answer the question: "for some value X with type T, find any fn call that COULD have produced this value". That would require significant changes to `generator_interior.rs`, and I would need mentorship on that. `@eholk` and I are discussing it. 3. `@estebank` do you know a way I can make the user-provided `reason` note pop out? right now it seems quite hidden Also, I am not sure if we should run perf on this r? `@nikomatsakis`
2021-09-21Use ZST for fmt unsafetyCameron Steffen-0/+1
This allows the format_args! macro to keep the pre-expansion code out of the unsafe block without doing gymnastics with nested `match` expressions. This reduces codegen.
2021-09-20Avoid the overflow with rustc+debugassertions in issue-44406Oli Scherer-6/+23
2021-09-20Add some more tracingOli Scherer-2/+6
2021-09-19Auto merge of #89049 - Aaron1011:caching-sourcemap-assert, r=Mark-Simulacrumbors-7/+7
Convert `debug_assert` to `assert` in `CachingSourceMapView` I suspect that there's a bug somewhere in this code, which is leading to the `predicates_of` ICE being seen in #89035
2021-09-19Rollup merge of #88855 - calebzulawski:feature/simd_shuffle, r=nagisaYuki Okushi-0/+1
Allow simd_shuffle to accept vectors of any length cc ``@rust-lang/project-portable-simd`` ``@workingjubilee``
2021-09-18Auto merge of #88978 - bjorn3:move_symbol_interner_lock, r=Mark-Simulacrumbors-23/+24
Move the Lock into symbol::Interner This makes it easier to make the symbol interner (near) lock free in case of concurrent accesses in the future. With https://github.com/rust-lang/rust/pull/87867 landed this shouldn't affect performance anymore.
2021-09-17Convert `debug_assert` to `assert` in `CachingSourceMapView`Aaron Hill-7/+7
I suspect that there's a bug somewhere in this code, which is leading to the `predicates_of` ICE being seen in #89035
2021-09-17Rollup merge of #88954 - nbdd0121:panic3, r=oli-obkGuillaume Gomez-0/+1
Allow `panic!("{}", computed_str)` in const fn. Special-case `panic!("{}", arg)` and translate it to `panic_display(&arg)`. `panic_display` will behave like `panic_any` in cosnt eval and behave like `panic!(format_args!("{}", arg))` in runtime. This should bring Rust 2015 and 2021 to feature parity in terms of `const_panic`; and hopefully would unblock the stabilisation of #51999. `@rustbot` modify labels: +T-compiler +T-libs +A-const-eval +A-const-fn r? `@oli-obk`
2021-09-17Auto merge of #88832 - pcwalton:debug-unit-variant-fast-path, r=oli-obkbors-0/+1
Introduce a fast path that avoids the `debug_tuple` abstraction when deriving Debug for unit-like enum variants. The intent here is to allow LLVM to remove the switch entirely in favor of an indexed load from a table of constant strings, which is likely what the programmer would write in C. Unfortunately, LLVM currently doesn't perform this optimization due to a bug, but there is [a patch](https://reviews.llvm.org/D109565) that fixes this issue. I've verified that, with that patch applied on top of this commit, Debug for unit-like tuple variants becomes a load, reducing the O(n) code bloat to O(1). Note that inlining `DebugTuple::finish()` wasn't enough to allow LLVM to optimize the code properly; I had to avoid the abstraction entirely. Not using the abstraction is likely better for compile time anyway. Part of #88793. r? `@oli-obk`
2021-09-16Rollup merge of #88875 - notriddle:notriddle/cleanup-unused-trait-selection, ↵Manish Goregaokar-1/+0
r=Mark-Simulacrum cleanup(rustc_trait_selection): remove vestigial code from rustc_on_unimplemented This isn't allowed by the validator, and seems to be unused. When it was added in ed10a3faae1fd1176b2edf4a61438e0542c103b9, it was used on `Sized`, and that usage is gone.
2021-09-15Rollup merge of #88775 - pnkfelix:revert-anon-union-parsing, r=davidtwcoManish Goregaokar-1/+0
Revert anon union parsing Revert PR #84571 and #85515, which implemented anonymous union parsing in a manner that broke the context-sensitivity for the `union` keyword and thus broke stable Rust code. Fix #88583.
2021-09-15Allow `panic!("{}", computed_str)` in const fn.Gary Guo-0/+1
2021-09-15Make two functions privatebjorn3-2/+2
2021-09-15Inline with_internerbjorn3-9/+5
2021-09-15Move the Lock into symbol::Internerbjorn3-16/+21
This makes it easier to make the symbol interner (near) lock free in case of concurrent accesses in the future.
2021-09-13Use a separate interner type for UniqueTypeIdbjorn3-1/+4
Using symbol::Interner makes it very easy to mixup UniqueTypeId symbols with the global interner. In fact the Debug implementation of UniqueTypeId did exactly this. Using a separate interner type also avoids prefilling the interner with unused symbols and allow for optimizing the symbol interner for parallel access without negatively affecting the single threaded module codegen.
2021-09-11cleanup(rustc_trait_selection): remove vestigial code from ↵Michael Howell-1/+0
rustc_on_unimplemented This isn't allowed by the validator, and seems to be unused. When it was added in ed10a3faae1fd1176b2edf4a61438e0542c103b9, it was used on `Sized`, and that usage is gone.
2021-09-11Auto merge of #84373 - cjgillot:resolve-span, r=michaelwoerister,petrochenkovbors-30/+94
Encode spans relative to the enclosing item The aim of this PR is to avoid recomputing queries when code is moved without modification. MCP at https://github.com/rust-lang/compiler-team/issues/443 This is achieved by : 1. storing the HIR owner LocalDefId information inside the span; 2. encoding and decoding spans relative to the enclosing item in the incremental on-disk cache; 3. marking a dependency to the `source_span(LocalDefId)` query when we translate a span from the short (`Span`) representation to its explicit (`SpanData`) representation. Since all client code uses `Span`, step 3 ensures that all manipulations of span byte positions actually create the dependency edge between the caller and the `source_span(LocalDefId)`. This query return the actual absolute span of the parent item. As a consequence, any source code motion that changes the absolute byte position of a node will either: - modify the distance to the parent's beginning, so change the relative span's hash; - dirty `source_span`, and trigger the incremental recomputation of all code that depends on the span's absolute byte position. With this scheme, I believe the dependency tracking to be accurate. For the moment, the spans are marked during lowering. I'd rather do this during def-collection, but the AST MutVisitor is not practical enough just yet. The only difference is that we attach macro-expanded spans to their expansion point instead of the macro itself.
2021-09-11must_not_suspend implGus Wynn-0/+1
2021-09-11Allow simd_shuffle to accept vectors of any lengthCaleb Zulawski-0/+1
2021-09-11don't clone types that are Copy (clippy::clone_on_copy)Matthias Krüger-3/+1
2021-09-10Introduce a fast path that avoids the `debug_tuple` abstraction when derivingPatrick Walton-0/+1
Debug for unit-like enum variants. The intent here is to allow LLVM to remove the switch entirely in favor of an indexed load from a table of constant strings, which is likely what the programmer would write in C. Unfortunately, LLVM currently doesn't perform this optimization due to a bug, but there is [a patch](https://reviews.llvm.org/D109565) that fixes this issue. I've verified that, with that patch applied on top of this commit, Debug for unit-like tuple variants becomes a load, reducing the O(n) code bloat to O(1). Note that inlining `DebugTuple::finish()` wasn't enough to allow LLVM to optimize the code properly; I had to avoid the abstraction entirely. Not using the abstraction is likely better for compile time anyway. Part of #88793.
2021-09-10Remove some span tracking.Camille GILLOT-6/+6
2021-09-10Rename decode to data_untracked.Camille GILLOT-4/+4
2021-09-10Track span dependency using a callback.Camille GILLOT-2/+19
2021-09-10Encode spans relative to their parent.Camille GILLOT-3/+17
2021-09-10Keep a parent LocalDefId in SpanData.Camille GILLOT-22/+55
2021-09-09Ignore automatically derived impls of `Clone` and `Debug` in dead code analysisFabian Wolff-0/+1
2021-09-09Revert "Implement Anonymous{Struct, Union} in the AST"Felix S. Klock II-1/+0
This reverts commit 059b68dd677808e14e560802d235ad40beeba71e. Note that this was manually adjusted to retain some of the refactoring introduced by commit 059b68dd677808e14e560802d235ad40beeba71e, so that it could likewise retain the correction introduced in commit 5b4bc05fa57be19bb5962f4b7c0f165e194e3151
2021-09-08Bump stage0 compiler to 1.56Mark Rousskov-1/+0
2021-09-03Auto merge of #88363 - michaelwoerister:remapped-diagnostics, r=estebankbors-16/+38
Path remapping: Make behavior of diagnostics output dependent on presence of --remap-path-prefix. This PR fixes a regression (#87745) with `--remap-path-prefix` where the flag stopped causing diagnostic messages to be remapped as well. The regression was introduced in https://github.com/rust-lang/rust/pull/83813 where we erroneously assumed that remapping of diagnostic messages was not desired anymore (because #70642 partially undid that functionality with nobody objecting). The issue is fixed by making `--remap-path-prefix` remap diagnostic messages again, including for paths that have been remapped in upstream crates (e.g. the standard library). This means that "sysroot-localization" (implemented in #70642) is also disabled if `rustc` is invoked with `--remap-path-prefix`. The assumption is that once someone starts explicitly remapping paths they also don't want paths to their local Rust installation in their build output. In the future we might want to give more fine-grained control over this behavior via compiler flags (see https://github.com/rust-lang/rfcs/pull/3127 for a related RFC). For now this PR is intended as a regression fix. This PR is an alternative to https://github.com/rust-lang/rust/pull/88191, which makes diagnostic messages be remapped unconditionally. That approach, however, would effectively revert #70642. Fixes https://github.com/rust-lang/rust/issues/87745. cc `@cbeuw` r? `@ghost`
2021-09-01Rollup merge of #88350 - programmerjake:add-ppc-cr-xer-clobbers, r=AmanieuMara Bos-0/+2
add support for clobbering xer, cr, and cr[0-7] for asm! on OpenPower/PowerPC Fixes #88315
2021-09-01Auto merge of #87688 - camsteffen:let-else, r=cjgillotbors-0/+3
Introduce `let...else` Tracking issue: #87335 The trickiest part for me was enforcing the diverging else block with clear diagnostics. Perhaps the obvious solution is to expand to `let _: ! = ..`, but I decided against this because, when a "mismatched type" error is found in typeck, there is no way to trace where in the HIR the expected type originated, AFAICT. In order to pass down this information, I believe we should introduce `Expectation::LetElseNever(HirId)` or maybe add `HirId` to `Expectation::HasType`, but I left that as a future enhancement. For now, I simply assert that the block is `!` with a custom `ObligationCauseCode`, and I think this is clear enough, at least to start. The downside here is that the error points at the entire block rather than the specific expression with the wrong type. I left a todo to this effect. Overall, I believe this PR is feature-complete with regard to the RFC.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-13 19:13:20 +0000