about summary refs log tree commit diff
path: root/compiler/rustc_span/src
AgeCommit message (Collapse)AuthorLines
2025-02-03Contracts core intrinsics.Felix S. Klock II-0/+4
These are hooks to: 1. control whether contract checks are run 2. allow 3rd party tools to intercept and reintepret the results of running contracts.
2025-02-03tree-wide: parallel: Fully removed all `Lrc`, replaced with `Arc`Askar Safin-61/+62
2025-02-02Remove dead control char logicreal-eren-120/+55
Only newlines and multibyte characters are actually relevant
2025-02-02Simplify SSE2 implementationreal-eren-18/+6
2025-02-02Rollup merge of #136422 - nnethercote:convert-lint-functions, r=NoratriebMatthias Krüger-0/+32
Convert two `rustc_middle::lint` functions to `Span` methods. `rustc_middle` is a huge crate and it's always good to move stuff out of it. There are lots of similar methods already on `Span`, so these two functions, `in_external_macro` and `is_from_async_await`, fit right in. The diff is big because `in_external_macro` is used a lot by clippy lints. r? ``@Noratrieb``
2025-02-02Rollup merge of #134272 - RalfJung:destabilize-rustc_encodable_decodable, ↵Matthias Krüger-2/+0
r=oli-obk Remove rustc_encodable_decodable feature This has been shown in future-compat reports since Rust 1.79 (https://github.com/rust-lang/rust/pull/116016), released June 2024. Let's see if crater still finds any issues. Part of https://github.com/rust-lang/rust/issues/134301. Cc ``@rust-lang/libs-api``
2025-02-02Convert two `rustc_middle::lint` functions to `Span` methods.Nicholas Nethercote-0/+32
`rustc_middle` is a huge crate and it's always good to move stuff out of it. There are lots of similar methods already on `Span`, so these two functions, `in_external_macro` and `is_from_async_await`, fit right in. The diff is big because `in_external_macro` is used a lot by clippy lints.
2025-02-01Rollup merge of #130514 - compiler-errors:unsafe-binders, r=oli-obkMatthias Krüger-1/+0
Implement MIR lowering for unsafe binders This is the final bit of the unsafe binders puzzle. It implements MIR, CTFE, and codegen for unsafe binders, and enforces that (for now) they are `Copy`. Later on, I'll introduce a new trait that relaxes this requirement to being "is `Copy` or `ManuallyDrop<T>`" which more closely models how we treat union fields. Namely, wrapping unsafe binders is now `Rvalue::WrapUnsafeBinder`, which acts much like an `Rvalue::Aggregate`. Unwrapping unsafe binders are implemented as a MIR projection `ProjectionElem::UnwrapUnsafeBinder`, which acts much like `ProjectionElem::Field`. Tracking: - https://github.com/rust-lang/rust/issues/130516
2025-01-31Add `unchecked_disjoint_bitor` with fallback intrinsic implementationScott McMurray-0/+1
2025-01-31Implement MIR, CTFE, and codegen for unsafe bindersMichael Goulet-1/+0
2025-01-31Auto merge of #134424 - 1c3t3a:null-checks, r=saethlinbors-0/+1
Insert null checks for pointer dereferences when debug assertions are enabled Similar to how the alignment is already checked, this adds a check for null pointer dereferences in debug mode. It is implemented similarly to the alignment check as a `MirPass`. This inserts checks in the same places as the `CheckAlignment` pass and additionally also inserts checks for `Borrows`, so code like ```rust let ptr: *const u32 = std::ptr::null(); let val: &u32 = unsafe { &*ptr }; ``` will have a check inserted on dereference. This is done because null references are UB. The alignment check doesn't cover these places, because in `&(*ptr).field`, the exact requirement is that the final reference must be aligned. This is something to consider further enhancements of the alignment check. For now this is implemented as a separate `MirPass`, to make it easy to disable this check if necessary. This is related to a 2025H1 project goal for better UB checks in debug mode: https://github.com/rust-lang/rust-project-goals/pull/177. r? `@saethlin`
2025-01-31Insert null checks for pointer dereferences when debug assertions are enabledBastian Kersting-0/+1
Similar to how the alignment is already checked, this adds a check for null pointer dereferences in debug mode. It is implemented similarly to the alignment check as a MirPass. This is related to a 2025H1 project goal for better UB checks in debug mode: https://github.com/rust-lang/rust-project-goals/pull/177.
2025-01-31Rollup merge of #133429 - EnzymeAD:autodiff-middle, r=oli-obkJacob Pratt-2/+0
Autodiff Upstreaming - rustc_codegen_ssa, rustc_middle This PR should not be merged until the rustc_codegen_llvm part is merged. I will also alter it a little based on what get's shaved off from the cg_llvm PR, and address some of the feedback I received in the other PR (including cleanups). I am putting it already up to 1) Discuss with `@jieyouxu` if there is more work needed to add tests to this and 2) Pray that there is someone reviewing who can tell me why some of my autodiff invocations get lost. Re 1: My test require fat-lto. I also modify the compilation pipeline. So if there are any other llvm-ir tests in the same compilation unit then I will likely break them. Luckily there are two groups who currently have the same fat-lto requirement for their GPU code which I have for my autodiff code and both groups have some plans to enable support for thin-lto. Once either that work pans out, I'll copy it over for this feature. I will also work on not changing the optimization pipeline for functions not differentiated, but that will require some thoughts and engineering, so I think it would be good to be able to run the autodiff tests isolated from the rest for now. Can you guide me here please? For context, here are some of my tests in the samples folder: https://github.com/EnzymeAD/rustbook Re 2: This is a pretty serious issue, since it effectively prevents publishing libraries making use of autodiff: https://github.com/EnzymeAD/rust/issues/173. For some reason my dummy code persists till the end, so the code which calls autodiff, deletes the dummy, and inserts the code to compute the derivative never gets executed. To me it looks like the rustc_autodiff attribute just get's dropped, but I don't know WHY? Any help would be super appreciated, as rustc queries look a bit voodoo to me. Tracking: - https://github.com/rust-lang/rust/issues/124509 r? `@jieyouxu`
2025-01-30implement unstable `new_range` featurePeter Jaszkowiak-0/+4
for RFC 3550, tracking issue #123741
2025-01-29upstream rustc_codegen_ssa/rustc_middle changes for enzyme/autodiffManuel Drehwald-2/+0
2025-01-28Rollup merge of #136071 - wowinter13:clippy-add-diagnostic-items, r=flip1995Matthias Krüger-0/+2
[Clippy] Add vec_reserve & vecdeque_reserve diagnostic items I’m currently working on reviving this lint (https://github.com/rust-lang/rust-clippy/pull/10157), and there was [a comment](https://github.com/rust-lang/rust-clippy/pull/10157#discussion_r1091591057) from ``@flip1995`` regarding the necessity of adding new diagnostic items.
2025-01-25[Clippy] Add vec_reserve & vecdeque_reserve diagnostic itemswowinter13-0/+2
2025-01-25Rollup merge of #134300 - RalfJung:remove-dead-attrs, r=chenyukangMatthias Krüger-2/+0
remove long-deprecated no-op attributes no_start and crate_id These have emitted a deprecation warning since forever (https://github.com/rust-lang/rust/pull/64471) and they already don't do anything. In fact they [apparently](https://github.com/rust-lang/rust/pull/64471#issuecomment-531517332) have done nothing since pre-1.0, so... do we even need a crater run? Doesn't seem worth it.
2025-01-25Auto merge of #119286 - jyn514:linker-output, r=bjorn3bors-0/+1
show linker output even if the linker succeeds Show stderr and stderr by default, controlled by a new `linker_messages` lint. fixes https://github.com/rust-lang/rust/issues/83436. fixes https://github.com/rust-lang/rust/issues/38206. cc https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/uplift.20some.20-Zverbose.20calls.20and.20rename.20to.E2.80.A6.20compiler-team.23706/near/408986134 <!-- try-job: dist-x86_64-msvc --> try-job: aarch64-apple r? `@bjorn3`
2025-01-22Auto merge of #134478 - compiler-errors:attr-span, r=oli-obkbors-6/+39
Properly record metavar spans for other expansions other than TT This properly records metavar spans for nonterminals other than tokentree. This means that we operations like `span.to(other_span)` work correctly for macros. As you can see, other diagnostics involving metavars have improved as a result. Fixes #132908 Alternative to #133270 cc `@ehuss` cc `@petrochenkov`
2025-01-21remove long-deprecated no-op attributes no_start and crate_idRalf Jung-2/+0
2025-01-20warn on unused linker_messages warning attributesjyn-0/+1
2025-01-19Rename FileName::QuoteExpansion to CfgSpecEric Huss-5/+5
I believe this variant name was used incorrectly. The timeline is roughly: * `FileName::cfg_spec_source_code` was added in https://github.com/rust-lang/rust/pull/54517. However, it used `FileName::Quote` instead of `FileName::CfgSpec` which I believe was a mistake. * Quote stuff was removed in https://github.com/rust-lang/rust/pull/51285, but did not remove `FileName::Quote`. * `FileName::CfgSpec` was removed in https://github.com/rust-lang/rust/pull/116474 because it was unused. This restores it so that the `--cfg` variant uses a name that makes more sense with how it is used, and restores what I think is the original intent.
2025-01-18Revert "Auto merge of #133734 - scottmcm:lower-indexing-to-ptrmetadata, ↵Rémy Rakic-4/+0
r=davidtwco,RalfJung" This reverts commit b57d93d8b9525fa261404b4cd9c0670eeb1264b8, reversing changes made to 0aeaa5eb22180fdf12a8489e63c4daa18da6f236.
2025-01-18Revert "Auto merge of #134330 - scottmcm:no-more-rvalue-len, r=matthewjasper"Rémy Rakic-0/+1
This reverts commit e108481f74ff123ad98a63bd107a18d13035b275, reversing changes made to 303e8bd768526a5812bb1776e798e829ddb7d3ca.
2025-01-17Auto merge of #135047 - Flakebi:amdgpu-kernel-cc, r=workingjubileebors-0/+1
Add gpu-kernel calling convention The amdgpu-kernel calling convention was reverted in commit f6b21e90d1ec01081bc2619efb68af6788a63d65 (#120495 and https://github.com/rust-lang/rust-analyzer/pull/16463) due to inactivity in the amdgpu target. Introduce a `gpu-kernel` calling convention that translates to `ptx_kernel` or `amdgpu_kernel`, depending on the target that rust compiles for. Tracking issue: #135467 amdgpu target tracking issue: #135024
2025-01-16Auto merge of #135592 - matthiaskrgr:rollup-4t69l7i, r=matthiaskrgrbors-0/+1
Rollup of 7 pull requests Successful merges: - #134754 (Implement `use` associated items of traits) - #135481 (coverage: Completely overhaul counter assignment, using node-flow graphs) - #135504 (Allow coercing safe-to-call target_feature functions to safe fn pointers) - #135561 (Update docs for `-Clink-dead-code` to discourage its use) - #135574 (ci: mirror ubuntu:22.04 to ghcr.io) - #135585 (resolve symlinks of LLVM tool binaries before copying them) - #135588 (Add license-metadata.json to rustc-src tarball.) r? `@ghost` `@rustbot` modify labels: rollup
2025-01-16Rollup merge of #134754 - ↵Matthias Krüger-0/+1
frank-king:feature/import_trait_associated_functions, r=oli-obk Implement `use` associated items of traits This PR implements #134691.
2025-01-16Rollup merge of #133720 - c410-f3r:cfg-match-foo-bar-baz, r=joshtriplettMatthias Krüger-0/+160
[cfg_match] Adjust syntax A year has passed since the creation of #115585 and the feature, as expected, is not moving forward. Let's change that. This PR proposes changing the arm's syntax from `cfg(SOME_CONDITION) => { ... }` to `SOME_CODITION => {}`. ```rust match_cfg! { unix => { fn foo() { /* unix specific functionality */ } } target_pointer_width = "32" => { fn foo() { /* non-unix, 32-bit functionality */ } } _ => { fn foo() { /* fallback implementation */ } } } ``` Why? Because after several manual migrations in https://github.com/rust-lang/rust/pull/116342 it became clear, at least for me, that `cfg` prefixes are unnecessary, verbose and redundant. Again, everything is just a proposal to move things forward. If the shown syntax isn't ideal, feel free to close this PR or suggest other alternatives.
2025-01-16Implement `use` associated items of traitsFrank King-0/+1
2025-01-16Add gpu-kernel calling conventionFlakebi-0/+1
The amdgpu-kernel calling convention was reverted in commit f6b21e90d1ec01081bc2619efb68af6788a63d65 due to inactivity in the amdgpu target. Introduce a `gpu-kernel` calling convention that translates to `ptx_kernel` or `amdgpu_kernel`, depending on the target that rust compiles for.
2025-01-14remove Rustc{En,De}codable from library and compilerRalf Jung-2/+0
2025-01-10mir_transform: implement forced inliningDavid Wood-0/+1
Adds `#[rustc_force_inline]` which is similar to always inlining but reports an error if the inlining was not possible, and which always attempts to inline annotated items, regardless of optimisation levels. It can only be applied to free functions to guarantee that the MIR inliner will be able to resolve calls.
2025-01-09Auto merge of #135268 - pietroalbini:pa-bump-stage0, r=Mark-Simulacrumbors-1/+1
Master bootstrap update Part of the release process. r? `@Mark-Simulacrum`
2025-01-08Add a list of symbols for stable standard library cratesTrevor Gross-1/+5
There are a few locations where the crate name is checked against an enumerated list of `std`, `core`, `alloc`, and `proc_macro`, or some subset thereof. In most of these cases, all four crates should likely be treated the same. Change this so the crates are listed in one place, and that list is used wherever a list of `std` crates is needed. `test` could be considered relevant in some of these cases, but generally treating it separate from the others seems preferable while it is unstable. There are also a few places that Clippy will be able to use this.
2025-01-08update cfg(bootstrap)Pietro Albini-1/+1
2025-01-06Rollup merge of #131830 - hoodmane:emscripten-wasm-eh, r=workingjubileeJacob Pratt-0/+2
Add support for wasm exception handling to Emscripten target This is a draft because we need some additional setting for the Emscripten target to select between the old exception handling and the new exception handling. I don't know how to add a setting like that, would appreciate advice from Rust folks. We could maybe choose to use the new exception handling if `Ctarget-feature=+exception-handling` is passed? I tried this but I get errors from llvm so I'm not doing it right.
2025-01-06Add support for wasm exception handling to Emscripten targetHood Chatham-0/+2
Gated behind an unstable `-Z emscripten-wasm-eh` flag
2025-01-06Add `kl` and `widekl` target features, and the feature gateSayantan Chakraborty-0/+1
2025-01-03turn rustc_box into an intrinsicRalf Jung-1/+0
2024-12-30Auto merge of #134757 - RalfJung:const_swap, r=scottmcmbors-1/+1
stabilize const_swap libs-api FCP passed in https://github.com/rust-lang/rust/issues/83163. However, I only just realized that this actually involves an intrinsic. The intrinsic could be implemented entirely with existing stable const functionality, but we choose to make it a primitive to be able to detect more UB. So nominating for `@rust-lang/lang` to make sure they are aware; I leave it up to them whether they want to FCP this. While at it I also renamed the intrinsic to make the "nonoverlapping" constraint more clear. Fixes #83163
2024-12-27Rollup merge of #134834 - dtolnay:unnamedcall, r=compiler-errorsDavid Tolnay-0/+6
Skip parenthesis around tuple struct field calls The pretty-printer previously did not distinguish between named vs unnamed fields when printing a function call containing a struct field. It would print the call as `(self.fun)()` for a named field which is correct, and `(self.0)()` for an unnamed field which is redundant. This PR changes function calls of tuple struct fields to print without parens. **Before:** ```rust struct Tuple(fn()); fn main() { let tuple = Tuple(|| {}); (tuple.0)(); } ``` **After:** ```rust struct Tuple(fn()); fn main() { let tuple = Tuple(|| {}); tuple.0(); } ```
2024-12-27Skip parenthesis around tuple struct field callsDavid Tolnay-0/+6
2024-12-27Move `{widening, carrying}_mul` to an intrinsic with fallback MIRScott McMurray-0/+1
Including implementing it for `u128`, so it can be defined in `uint_impl!`. This way it works for all backends, including CTFE.
2024-12-25rename typed_swap → typed_swap_nonoverlappingRalf Jung-1/+1
2024-12-24Auto merge of #134625 - compiler-errors:unsafe-binders-ty, r=oli-obkbors-0/+1
Begin to implement type system layer of unsafe binders Mostly TODOs, but there's a lot of match arms that are basically just noops so I wanted to split these out before I put up the MIR lowering/projection part of this logic. r? oli-obk Tracking: - https://github.com/rust-lang/rust/issues/130516
2024-12-22Begin to implement type system layer of unsafe bindersMichael Goulet-0/+1
2024-12-22Adjust syntaxCaio-0/+160
2024-12-22Delete `Rvalue::Len`Scott McMurray-1/+0
Everything's moved to `PtrMetadata` instead.
2024-12-21Hash only the spans that we care ended up reading in Span::try_metavarsMichael Goulet-14/+35