Skip to content

Trace task names in logging macros #2672

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

Closed
graydon opened this issue Jun 21, 2012 · 9 comments
Closed

Trace task names in logging macros #2672

graydon opened this issue Jun 21, 2012 · 9 comments
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.

Comments

@graydon
Copy link
Contributor

graydon commented Jun 21, 2012

Logging should emit task names, not just main. Probably task names should migrate to task-locals, when they exist, and logging should move to core.

@eholk
Copy link
Contributor

eholk commented Jul 23, 2012

Even just a task ID would be helpful until we have support for names.

The subject of task names came up recently in #2931.

@bstrie
Copy link
Contributor

bstrie commented Jun 24, 2013

@brson, is this still relevant with the new runtime work?

@emberian
Copy link
Member

/cc @bblum
Tasks seem to have names now, and I see them when a task fails.

@bblum
Copy link
Contributor

bblum commented Aug 11, 2013

They are not yet emitted during, for example, error! calls.

@catamorphism
Copy link
Contributor

Just a bug, de-milestoning

@flaper87
Copy link
Contributor

flaper87 commented Oct 1, 2013

I'll work on this

@alexcrichton
Copy link
Member

Updated the issue title to be more relevant to today's use-case

reem added a commit to reem/rust that referenced this issue Dec 1, 2014
This requires doing an allocation on log! invocations
if the current task is named, since there is no non-allocating
way to access the name of the current task.

Fixes rust-lang#2672
@reem
Copy link
Contributor

reem commented Dec 1, 2014

Triage: attempting to fix in #19444.

@alexcrichton
Copy link
Member

Fixed in #19444

celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Enforce that no warning is being added as part of our regression script instead at a crate level. This will also enforce no warnings for all our crates, instead of just kani-compiler as is today.

This makes development a bit easier, since warnings of unused code shows up fairly often when a feature is half implemented. So this allow us to compile and test the code before it's production ready. That said, it is nice to avoid warnings from piling up, so change the check to the regression instead, which should be executed before we create PR / merge changes.

This also aligns with the recommendation from
https://rust-unofficial.github.io/patterns/anti_patterns/deny-warnings.html
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-hard Call for participation: Hard difficulty. Experience needed to fix: A lot.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants