-
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
The code runs slower when optimised #5949
Comments
It seems to be because of stack switching. With -O:
|
Maybe it can print some warning that suggest me to set RUST_MIN_STACK? |
Now that pcwalton's improvements have landed, building with optimizations doesn't run slower than without optimizations. |
flip1995
pushed a commit
to flip1995/rust
that referenced
this issue
Aug 28, 2020
…le_const, r=oli-obk Fix fp in `borrow_interior_mutable_const` fixes rust-lang#5796 changelog: fix false positive in `borrow_interior_mutable_const` when referencing a field behind a pointer.
arcnmx
pushed a commit
to arcnmx/rust
that referenced
this issue
Jan 9, 2023
Add action to expand a declarative macro once, inline. Fixes rust-lang#13598 This commit adds a new r-a method, `expandMacroInline`, which expands the macro that's currently selected. See rust-lang#13598 for the most applicable issue; though I suspect it'll resolve part of rust-lang#5949 and make rust-lang#11888 significantly easier). The macro works like this: ![rust-analyser-feature](https://user-images.githubusercontent.com/10906982/208813167-3123e379-8fd5-4206-a4f4-5af1129565f9.gif) I have 2 questions before this PR can be merged: 1. **Should we rustfmt the output?** The advantage of doing this is neater code. The disadvantages are we'd have to format the whole expr/stmt/block (since there's no point just formatting one part, especially over multiple lines), and maybe it moves the code around more in weird ways. My suggestion here is to start off by not doing any formatting; and if it appears useful we can decide to do formatting in a later release. 2. **Is it worth solving the `$crate` hygiene issue now?** -- I think this PR is usable as of right now for some use-cases; but it is annoying that many common macros (i.e. `println!()`, `format!()`) can't be expanded further unless the user guesses the correct `$crate` value. The trouble with solving that issue is that I think it's complicated and imperfect. If we do solve it; we'd also need to either change the existing `expandMacro`/`expandMacroInline` commands; provide some option to allow/disallow `$crate` expanding; or come to some other compromise.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Built with rustc --opt-level 0, it runs fast.
With any other --opt-level, it runs slow.
Checked on c2f5a87 and 5f13e9c.
The text was updated successfully, but these errors were encountered: