Skip to content
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.

Sign up for GitHub

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

Jump to bottom

make clean should delete the tmp directory #12966

Closed
nrc opened this issue Mar 17, 2014 · 4 comments
Closed

make clean should delete the tmp directory #12966

nrc opened this issue Mar 17, 2014 · 4 comments
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@nrc
Copy link
Member

nrc commented Mar 17, 2014

I just had a bug where make check failed at run-pass/linkage2.rs. Deleting the tmp directory solved the problem, but make clean did not. I assume make clean should delete that sort of thing.
@flaper87
Copy link
Contributor

Triage bump, bug is still valid.

@flaper87 flaper87 added the E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. label Mar 23, 2015
@tbelaire
Copy link
Contributor

I don't understand why it didn't.

mk/clean.mk

 38 clean: clean-misc $(CLEAN_STAGE_RULES)
 39 
 40 clean-misc:
 41     @$(call E, cleaning)
 ...
 45     $(Q)rm -Rf tmp/*

So make clean does rm -Rf tmp/*. Perhaps it needs to delete the directory too?

Can I get more detailed steps on how to reproduce this bug, so I can tell if deleting tmp/ instead of tmp/* fixes it?

tbelaire added a commit to tbelaire/rust that referenced this issue Apr 14, 2015
@tbelaire
make clean deletes tmp, not tmp/*
5860167 
This might fix bug rust-lang#12966.
@tbelaire tbelaire mentioned this issue Apr 14, 2015
Closed
@steveklabnik
Copy link
Member

I agree with @tbelaire , it would seem like the rules are very straightforward here, and if I run make clean, I do get a rm -Rf tmp/*. @nrc or @flaper87 , can you give any way to reproduce this?

@brson
Copy link
Contributor

brson commented Jun 28, 2016

Ancient bug. Closing.

@brson brson closed this as completed Jun 28, 2016
matthiaskrgr pushed a commit to matthiaskrgr/rust that referenced this issue Oct 11, 2022
@bors
Auto merge of rust-lang#12966 - OleStrohm:master, r=Veykril
817a6a8 
feat: Display the value of enum variant on hover

fixes rust-lang#12955

This PR adds const eval support for enums, as well as showing their value on hover, just as consts currently have.

I developed these two things at the same time, but I've realized now that they are separate. However since the hover is just a 10 line change (not including tests), I figured I may as well put them in the same PR. Though if you want them split up into "enum const eval support"  and "show enum variant value on hover", I think that's reasonable too.

Since this adds const eval support for enums this also allows consts that reference enums to have their values computed now too.

The const evaluation itself is quite rudimentary, it doesn't keep track of the actual type of the enum, but it turns out that Rust doesn't actually either, and `E::A as u8` is valid regardless of the `repr` on `E`.

It also doesn't really care about what expression the enum variant contains, it could for example be a string, despite that not being allowed, but I guess it's up to the `cargo check` diagnostics to inform of such issues anyway?
flip1995 pushed a commit to flip1995/rust that referenced this issue Jul 11, 2024
@bors
Auto merge of rust-lang#12966 - Rudxain:patch-1, r=dswij
f2c74e2 
Clarify that `modulo_one` only applies to ints

changelog: [`modulo_one`]: (docs) Clarify that it only applies to integers

This might be nitpicky, but it's more technically correct.

It also helps if a user skims through the docs, because they may believe it also applies to `{float}`s. This doc edit minimizes that possibility
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@flaper87 @steveklabnik @alexcrichton @brson @tbelaire @nrc