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

rusti: duplicate definitions are accepted but break all further interaction #5675

Closed
ben0x539 opened this issue Apr 2, 2013 · 4 comments
Closed

Comments

@ben0x539
Copy link
Contributor

ben0x539 commented Apr 2, 2013

sample session:

$ rusti
WARNING: The Rust REPL is experimental and may be
unstable. If you encounter problems, please use the
compiler instead.
rusti> fn f() {}
()
rusti> fn f() {}
()
rusti> 42;
<anon>:35:0: 35:10 error: duplicate definition of value f
<anon>:35 fn f() { }
          ^~~~~~~~~~
<anon>:33:0: 33:10 note: first definition of value f here:
<anon>:33 fn f() { }
          ^~~~~~~~~~
error: aborting due to previous error
rust: task failed at 'explicit failure', /home/ben/code/repos/rust/src/libsyntax/diagnostic.rs:99
@jbclements
Copy link
Contributor

Hang on... it's not at all clear to me that this should be fixed by allowing duplicate definitions. What's the semantic model for redefinitions? Scoping works differently for items, and it seems like we dodge a lot of questions by disallowing redefinitions here. In fact, it's not clear that the OP was actually asking for duplicate definitions, but simply for a better/earlier error message. Can I nominate this for WONTFIX ? Maybe I officially nominate it for not-a-bug / well-defined.

@ben0x539
Copy link
Contributor Author

I hoped we'd at least reject the duplicate definition right away rather than accepting it and then rejecting all further input, it doesn't seem very productive to brick the whole session but still accept input.

I'd also say that redefinitions are really helpful for exploratory programming in the REPL. So even if this change isn't optimal yet (I haven't tried it), it's probably better than the current behavior?

@jbclements
Copy link
Contributor

I certainly agree that it's far better to give an error message on the redefinition.

bors added a commit that referenced this issue Jun 13, 2013
More descriptive comments can be found throughout the code, but the bulk of this is that it addresses a vast number of issues with the old rusti model.

Closes #6772, #5675, #5469, and #6617
@alexcrichton
Copy link
Member

Closed by #7070

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

No branches or pull requests

3 participants