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

rustc --crate-type=dylib -o name produces name.exe on windows #13794

Closed
klutzy opened this issue Apr 27, 2014 · 4 comments
Closed

rustc --crate-type=dylib -o name produces name.exe on windows #13794

klutzy opened this issue Apr 27, 2014 · 4 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. I-needs-decision Issue: In need of a decision. O-windows Operating system: Windows P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue.

Comments

@klutzy
Copy link
Contributor

klutzy commented Apr 27, 2014 

$ touch empty.rs
$ rustc empty.rs --crate-type=dylib -o empty
$ ls
empty.exe
empty.rs

It produces empty if crate type is rlib or staticlib.
@alexcrichton
Copy link
Member

I've heard of the mingw ld silently putting the .exe suffix on outputs before, I also remember that there's some sort of switch to tell it to stop doing that. Then again, I also remember that we wanted this addition of .exe at least some of the time...

@brson brson mentioned this issue Aug 12, 2014
Closed
33 tasks
@pnkfelix
Copy link
Member

P-low, not 1.0.

@vadimcn
Copy link
Contributor

vadimcn commented Feb 20, 2015

Not sure this is wrong, actually. This is clearly a compatibility feature for the benefit of Unix-y shell scripts. On Unix executable files are designated by a permissions bit, but on Windows - by extension. If Windows ld were to create an extension-less file, it couldn't be executed.

@brson brson added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. I-needs-decision Issue: In need of a decision. T-tools labels Sep 22, 2016
@Mark-Simulacrum Mark-Simulacrum added T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. and removed T-tools labels May 24, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 21, 2017
@steveklabnik
Copy link
Member

This doesn't appear to happen today; at least, not with the MSVC toolchain, which is the recommended one. With no comments since 2015, including one that says this may not be a bug, I'm going to give this a close. If this is in error, please let me know!

arcnmx pushed a commit to arcnmx/rust that referenced this issue Jan 9, 2023
@bors
Auto merge of rust-lang#13794 - jonas-schievink:reset-step-limit-afte…
1f74b1b 
…r-bump, r=jonas-schievink

fix: fix "parser seems stuck" panic when parsing colossal files

The parser step count is incremented every time the parser inspects a token. It's purpose is to ensure the parser doesn't get stuck in infinite loops. But since `self.pos` grows monotonically when parsing source code, it gives a better idea for whether the parser is stuck or not: if `self.pos` is changed, we know that the parser cannot be stuck, so it is safe to reset the step count to 0. This makes the limit check scale with the size of the file, and so should fix rust-lang/rust-analyzer#13788.
flip1995 pushed a commit to flip1995/rust that referenced this issue Dec 15, 2024
@Centri3
Update known problems for default_numeric_fallback (rust-lang#13794)
d1e1aff 
The existing known problem is not actually true, and the many false
positives and false negatives should be mentioned.

Allowing the lint on a single statement:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=328de43690af13ed126f7c00c15cd695

changelog: [`default_numeric_fallback`]: update known problems docs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. I-needs-decision Issue: In need of a decision. O-windows Operating system: Windows P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
8 participants
@steveklabnik @alexcrichton @brson @pnkfelix @huonw @klutzy @vadimcn @Mark-Simulacrum