Skip to content

Add Location::file_with_nul #135054

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 5, 2025
Merged

Add Location::file_with_nul #135054

merged 1 commit into from
Jun 5, 2025

Conversation

cramertj
Copy link
Member

@cramertj cramertj commented Jan 3, 2025

This is useful for C/C++ APIs which expect the const char* returned from FILE or std::source_location::file_name.

ACP: rust-lang/libs-team#466
Tracking issue: #141727

@rustbot
Copy link
Collaborator

rustbot commented Jan 3, 2025

r? @cuviper

rustbot has assigned @cuviper.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 3, 2025
@rustbot
Copy link
Collaborator

rustbot commented Jan 3, 2025

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @rust-lang/wg-const-eval

@Noratrieb
Copy link
Member

see rust-lang/libs-team#466

@cramertj
Copy link
Member Author

cramertj commented Jan 3, 2025

see rust-lang/libs-team#466

Renamed to file_with_nul as per that proposal.

@cramertj cramertj changed the title Add Location::file_cstr Add Location::file_with_nul Jan 3, 2025
@cramertj cramertj force-pushed the file-cstr branch 2 times, most recently from d28ac01 to 73810aa Compare January 3, 2025 17:24
@bjorn3
Copy link
Member

bjorn3 commented Jan 5, 2025

How does this compare with #131828?

@cramertj
Copy link
Member Author

cramertj commented Jan 6, 2025

@bjorn3 This is essentially the same feature, although this implementation doesn't require an increase to the size of the Location struct itself (and could actually be used to decrease it by dropping the size of the slice if we cared to do so).

@Darksonn
Copy link
Contributor

Darksonn commented Jan 7, 2025

The other PR does not change the size of the Location struct either.

Comment on lines 147 to 150
let str_len = self.file_bytes_with_nul.len() - 1;
// SAFETY: `file_bytes_with_nul` without the trailing nul byte is guaranteed to be
// valid UTF8.
unsafe { crate::str::from_raw_parts(self.file_bytes_with_nul.as_ptr(), str_len) }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

str is allowed to have null bytes within. So you could keep the type at &'a str and use &self.file[..self.file.len() -1] here without unsafe code

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could! I think that just moves the unsafety into a call to from_bytes_with_nul_unchecked for the CStr, though, so I think it's roughly the same either way.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That unsafety exists either way unless you just directly encode it as CStr, tho we're still holding out for that becoming a thin pointer, at which point it would be expensive to get the str out of it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it's simpler to just store a raw pointer and length without the nul-terminator included. That way, Location hold the integer we want most of the time without triggering provenance concerns.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That way, Location hold the integer we want most of the time without triggering provenance concerns.

What integer do you mean?

I wasn't aware of any provenance concerns, was that discussed in #131828?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The provenance discussion is in a hidden subthread above: #135054 (comment)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean that storing a raw pointer / length instead of a slice would let us store the length without the nul-terminator included, which makes more sense to me.

@cramertj
Copy link
Member Author

cramertj commented Jan 7, 2025

The other PR does not change the size of the Location struct either.

Thanks for the correction! I must've misread it when I saw it. In either case, I don't have a strong preference and am happy to remove this one if it makes life easier. I didn't know about the first PR when I wrote this one.

@Darksonn
Copy link
Contributor

Darksonn commented Jan 8, 2025

I closed my original PR in favor of this PR, and opened a new PR #135240 that shows how the alternative approach of adding a compiler flag would look.

@Noratrieb
Copy link
Member

Noratrieb commented Jan 8, 2025

Let's do a perf run to get a concrete binary size overhead (which will of course be so tiny that it's negligible, but having proof of that seems to be necessary in this discussion!).
@bors try @rust-timer queue

@rust-timer

This comment has been minimized.

@rustbot rustbot added the S-waiting-on-perf Status: Waiting on a perf run to be completed. label Jan 8, 2025
@bors
Copy link
Collaborator

bors commented Jan 8, 2025

⌛ Trying commit 73810aa with merge 35c365c...

bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 8, 2025
Add Location::file_with_nul

This is useful for C/C++ APIs which expect the const char* returned from __FILE__ or std::source_location::file_name.
@bors
Copy link
Collaborator

bors commented Jan 8, 2025

☀️ Try build successful - checks-actions
Build commit: 35c365c (35c365c6fce43dba6f1e28794102c6f406ba02d9)

Copy link
Member

@m-ou-se m-ou-se left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

r=me after adding tracking issue and removing the cfg attributes ❤️

@rustbot

This comment has been minimized.

This is useful for C/C++ APIs which expect the const char* returned
from __FILE__ or std::source_location::file_name.
@m-ou-se
Copy link
Member

m-ou-se commented Jun 4, 2025

bors r plus

@bors
Copy link
Collaborator

bors commented Jun 4, 2025

📌 Commit b541f93 has been approved by m-ou-se

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 4, 2025
bors added a commit that referenced this pull request Jun 5, 2025
Add Location::file_with_nul

This is useful for C/C++ APIs which expect the const char* returned from __FILE__ or std::source_location::file_name.

ACP: rust-lang/libs-team#466
Tracking issue: #141727
@bors
Copy link
Collaborator

bors commented Jun 5, 2025

⌛ Testing commit b541f93 with merge d1634d0...

@rust-log-analyzer
Copy link
Collaborator

The job dist-x86_64-apple failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[TIMING] core::build_steps::doc::TheBook { compiler: Compiler { stage: 2, host: x86_64-apple-darwin, forced_compiler: false }, target: x86_64-apple-darwin } -- 2.149
##[group]Documenting stage2 standalone (x86_64-apple-darwin)
##[endgroup]
[TIMING] core::build_steps::doc::Standalone { compiler: Compiler { stage: 2, host: x86_64-apple-darwin, forced_compiler: false }, target: x86_64-apple-darwin } -- 0.818
dyld[44097]: Library not loaded: @rpath/librustc_driver-0e8537a46b37ce74.dylib
  Referenced from: <0E2B9387-EEC1-3F9A-8FA4-7BED87576B3D> /Users/runner/work/rust/rust/build/x86_64-apple-darwin/stage1-rustc/x86_64-apple-darwin/release/rustc-main
  Reason: tried: '/Users/runner/work/rust/rust/build/x86_64-apple-darwin/stage1-rustc/x86_64-apple-darwin/release/../lib/librustc_driver-0e8537a46b37ce74.dylib' (no such file), '/Users/runner/work/rust/rust/build/x86_64-apple-darwin/stage1-rustc/x86_64-apple-darwin/release/../lib/librustc_driver-0e8537a46b37ce74.dylib' (no such file)
Command "/Users/runner/work/rust/rust/build/x86_64-apple-darwin/stage2/bin/rustc" "--target" "x86_64-apple-darwin" "--print=deployment-target" (failure_mode=Exit) has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 1:23:47
  local time: Thu Jun  5 05:25:39 UTC 2025
  network time: Thu, 05 Jun 2025 05:25:40 GMT
##[error]Process completed with exit code 1.
Post job cleanup.

@bors
Copy link
Collaborator

bors commented Jun 5, 2025

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 5, 2025
@m-ou-se
Copy link
Member

m-ou-se commented Jun 5, 2025

@bors retry

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 5, 2025
@bors
Copy link
Collaborator

bors commented Jun 5, 2025

⌛ Testing commit b541f93 with merge c360e21...

@bors
Copy link
Collaborator

bors commented Jun 5, 2025

☀️ Test successful - checks-actions
Approved by: m-ou-se
Pushing c360e21 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 5, 2025
@bors bors merged commit c360e21 into rust-lang:master Jun 5, 2025
11 checks passed
@rustbot rustbot added this to the 1.89.0 milestone Jun 5, 2025
Copy link
Contributor

github-actions bot commented Jun 5, 2025

What is this? This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 425e142 (parent) -> c360e21 (this PR)

Test differences

Show 12 test diffs

Stage 1

  • [ui] tests/ui/rfcs/rfc-2091-track-caller/file-is-nul-terminated.rs: [missing] -> pass (J0)

Stage 2

  • [ui] tests/ui/rfcs/rfc-2091-track-caller/file-is-nul-terminated.rs: [missing] -> pass (J1)

Additionally, 10 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard c360e219f5a56631baa46065d28e9852ca7d4ce3 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

  1. dist-apple-various: 5703.5s -> 9876.7s (73.2%)
  2. x86_64-apple-1: 5922.1s -> 7572.1s (27.9%)
  3. dist-aarch64-apple: 5742.9s -> 6609.7s (15.1%)
  4. x86_64-apple-2: 3552.1s -> 3130.4s (-11.9%)
  5. dist-x86_64-apple: 8479.4s -> 7514.7s (-11.4%)
  6. dist-armv7-linux: 5348.1s -> 4863.7s (-9.1%)
  7. dist-loongarch64-musl: 4761.0s -> 5139.6s (8.0%)
  8. aarch64-apple: 4342.9s -> 4005.1s (-7.8%)
  9. dist-various-1: 4483.9s -> 4146.4s (-7.5%)
  10. x86_64-msvc-2: 6435.7s -> 6891.8s (7.1%)
How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (c360e21): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
-0.2% [-0.3%, -0.2%] 5
All ❌✅ (primary) - - 0

Max RSS (memory usage)

Results (primary -1.2%, secondary -3.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
2.0% [2.0%, 2.0%] 1
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-4.5% [-4.5%, -4.5%] 1
Improvements ✅
(secondary)
-3.3% [-3.3%, -3.3%] 1
All ❌✅ (primary) -1.2% [-4.5%, 2.0%] 2

Cycles

Results (secondary 3.3%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
3.3% [3.3%, 3.3%] 1
Improvements ✅
(primary)
- - 0
Improvements ✅
(secondary)
- - 0
All ❌✅ (primary) - - 0

Binary size

Results (primary -0.1%, secondary -0.1%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
0.0% [0.0%, 0.0%] 3
Regressions ❌
(secondary)
0.0% [0.0%, 0.0%] 1
Improvements ✅
(primary)
-0.1% [-0.3%, -0.0%] 82
Improvements ✅
(secondary)
-0.1% [-1.7%, -0.0%] 61
All ❌✅ (primary) -0.1% [-0.3%, 0.0%] 85

Bootstrap: 749.811s -> 750.544s (0.10%)
Artifact size: 371.77 MiB -> 371.78 MiB (0.00%)

@cramertj cramertj deleted the file-cstr branch June 5, 2025 17:08
@bjorn3
Copy link
Member

bjorn3 commented Jun 5, 2025

This slightly improved the binary size. Likely because the string merging linker optimization now kicks in.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-panic Area: Panicking machinery A-rust-for-linux Relevant for the Rust-for-Linux project merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.