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

duplicate definition should report location of the definition #2391

Closed
erickt opened this issue May 17, 2012 · 4 comments
Closed

duplicate definition should report location of the definition #2391

erickt opened this issue May 17, 2012 · 4 comments
Labels
A-typesystem Area: The type system C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@erickt
Copy link
Contributor

erickt commented May 17, 2012

I'm running into this error:

./request.rs:1:7: 1:29 error: duplicate definition of type request
./request.rs:1 import mre::request::request;
                      ^~~~~~~~~~~~~~~~~~~~~~

even though I only import mre::request::request once in that file. Perhaps I'm running into a compiler bug, or maybe I just don't quite understand the import rules. So, it would be helpful if the duplicate definition error also reported where rust first found the definition.

@catamorphism
Copy link
Contributor

#2386 is related.

@nikomatsakis
Copy link
Contributor

I agree, it should print more details. @erickt likely the problem is an import in an outer scope. Why this is considered an error and not a shadow, I am not precisely sure, but I have seen it happen.

@gwillen
Copy link
Contributor

gwillen commented Jul 13, 2012

I was going to file a bug suggesting that duplicate definition should report more information; specifically, if the duplicate definition is in an impl, rather than just "to_str", I'd like to see "impl to_str of to_str for @t".

But giving me the location would also be good.

@catamorphism
Copy link
Contributor

The error message reports the first definition's span now.

bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
on an error, always print the unnormalized stderr

Currently we skip this if a stderr diff was printed, but the stderr diff is normalized, so e.g. one cannot learn line numbers from it.

Is there a way to get the diff to only print the parts the differ, like a usual `diff -u`? Currently it always seems to print the full output, so with a long stderr we now get doubly long test results even if the diff is actually rather small.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-typesystem Area: The type system C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

4 participants