-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Add -Zborrowck-unreachable=no #103356
Add -Zborrowck-unreachable=no #103356
Conversation
Your comparison to GHC's typed holes and Agda's holes is not right. These holes are in place of expressions (of course the lines blur in Agda) and their purpose is to cause the compiler to "complain" (with type information and suggestions on how to fill in the missing part). A more related feature is GHC's https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/defer_type_errors.html |
This comment was marked as resolved.
This comment was marked as resolved.
I think this flag is unnecessarily crudely named, and we really should probably rename it 😕 Though I am also pretty strongly against us landing any flag that intentionally skips checks like this.
I don't think this should be a motivation to land this flag -- codegen backends should not be designed to handle broken code gracefully. Post-monomorphization code should be designed assuming that it's getting code that has been validated and should ICE when it gets something like |
This comment was marked as resolved.
This comment was marked as resolved.
suggestion: |
Like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Naming bikeshedding aside, and agreeing with scottmcm on the intent, this should never even approach the appearance of being usable by end users. I'm honestly shocked at how little code was necessary to get this working. The bigger version of this would also replace bodies containing [type error]
with panic
s, so as to simplify the code-generation of invalid items.
fn dead_code(s: &str) -> &'static str { | ||
s | ||
} | ||
|
||
fn main() { | ||
println!("he he he") | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we actually call dead_code
, this will be UB but "work" as long as it is called with a static string, right? The "fully built version" of this would ideally have a way of catching misuses at runtime. It'd be useful to also emit the compile errors even though they are ignored, maybe marking them as such (but that can be worked around by calling rustc twice 🤷).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, borrowck will still run when creating the MIR for the function. This is pretty much unavoidable as one of the outputs of borrowck is the list of upvars for closures, which is necessary for building the MIR for closures and their callers.
An use case that you're not mentioning (but I would like to eventually support), is being able to run a project's test suite even in the face of compilation errors. Any tests that can execute, would do so, while those that encountered compile errors would appear as test failures. |
additional prior art: The eclipse compiler for java (ecj) will attempt to build broken code by replacing the invalid method bodies with exception-throwing stubs so one can still run tests and debug incomplete code. |
No mention of how it's insufficiently self-descriptive? (eg. |
I don't see that at all locally. For rustc object files contain dead code when using incr comp, but not when disabling incr comp. It is included for incr comp to improve cache reuse as changes to what functions are used by one cgu won't cause another cgu to include it or not this way. |
This comment was marked as resolved.
This comment was marked as resolved.
The magic button for when you don't care about whether your code works, you just want it to compile. Currently, this avoids running borrowck or typeck on dead code that isn't monomorphized. In the future, it could be extended to ignore (but still emit) parse errors, mismatches in generic parameters, uses of private items, as long as the use doesn't need to make it to codegen. However, I don't propose to put them under the same flag. There is precedent for this in Haskell as -f defer-type-errors: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/defer_type_errors.html Build systems also commonly have this as --keep-going, which ignores failed builds while continuing to run other builds that aren't dependent on the one that failed. Some example motivations: - When making a large refactor, run a single test that doesn't affect the rest of the codebase. In essence this is a "poor man's workspace", but adhoc and much faster than splitting out a single crate into multiple. - Prototype a new application where you're rapidly changing the code and don't need it to be precisely correct, just see if it could eventually be made to compile.
Done; it's now called
I agree, I removed that motivation. I still think the remaining motivations are real world use cases though.
Oops, that's my bad - the function name I was looking for was also part of the crate name, which misled me. Yes, dead code doesn't end up in the final binary (cc #104858). |
This is the internal-facing portion of rust-lang#103356; it should not be user-visible in any way.
This comment has been minimized.
This comment has been minimized.
not all processed items will actually be instantiated; wait to borrowck them until it actually happens
The job Click to see the possible cause of the failure (guessed by this bot)
|
By looking at the activity I infer that this is still in flux, so switching to waiting on author and to request a new review with By the way: do we really want to land this? I'm not a fan of "emoji-voting" :) I just wonder if this should get a wider explicit consensus. @rustbot author |
@apiraino this is waiting on me to make an MCP, I think |
I am not planning to drive this forward at this time. |
The magic button for when you don't care about whether your code works, you just want it to compile.
Currently, this avoids running borrowck or typeck on dead code that isn't monomorphized. In the future, it could be extended to ignore (but still emit) parse errors, mismatches in generic parameters, uses of private items, as long as the use doesn't need to make it to codegen.
There is precedent for this in Haskell as -f defer-type-errors: https://ghc.gitlab.haskell.org/ghc/doc/users_guide/exts/defer_type_errors.html
Build systems also commonly have this as --keep-going, which ignores failed builds while continuing to run other builds that aren't dependent on the one that failed.
Some example motivations:
Fixes #104858.
r? @estebank