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.

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

Fix printing negative signed literal in print_literal #18160

Merged
merged 1 commit into from
Oct 20, 2014

Conversation

koshlo
Copy link
Contributor

@koshlo koshlo commented Oct 19, 2014

Fix for issue #18091

The problem seems to be that ast_util::int_ty_to_string takes unsigned number, and no one adds - to result string. I've fixed it by putting - before result string using format!.

I've also added test_signed_int_to_string() to check if implementation is valid.

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

@alexcrichton
Copy link
Member

Thanks! Just to confirm, if you run this through --pretty expanded, it still has the negative sign, right?

fn main() {
    let a = -42i;
}

@koshlo
Copy link
Contributor Author

koshlo commented Oct 19, 2014

Yes, after running this code through --pretty expanded it does contain negative sign.

@alexcrichton
Copy link
Member

Thanks @koshlo!

bors added a commit that referenced this pull request Oct 19, 2014
Fix for issue #18091 

The problem seems to be that `ast_util::int_ty_to_string` takes unsigned number, and no one adds `-` to result string. I've fixed it by putting `-` before result string using `format!`.

I've also added `test_signed_int_to_string()` to check if implementation is valid.
@bors bors closed this Oct 20, 2014
@bors bors merged commit 49ec356 into rust-lang:master Oct 20, 2014
@koshlo koshlo deleted the to-source-fix branch October 20, 2014 06:24
@koshlo koshlo restored the to-source-fix branch October 25, 2014 09:51
lnicola pushed a commit to lnicola/rust that referenced this pull request Sep 25, 2024
fix: Fix name resolution when an import is resolved to some namespace and then later in the algorithm another namespace is added

The import is flagged as "indeterminate", and previously it was re-resolved, but only at the end of name resolution, when it's already too late for anything that depends on it.

This issue was tried to fix in rust-lang/rust-analyzer#2466, but it was not fixed fully.

That PR is also why IDE features did work: the import at the end was resolved correctly, so IDE features that re-resolved the macro path resolved it correctly.

I was concerned about the performance of this, but this doesn't seem to regress `analysis-stats .`, so I guess it's fine to land this. I have no idea about the incremental perf however and I don't know how to measure that, although when typing in `zbus` (including creating a new function, which should recompute the def map) completion was fast enough.

I didn't check what rustc does, so maybe it does something more performant, like keeping track of only possibly problematic imports.

Fixes rust-lang#18138.
Probably fixes rust-lang#17630.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants