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

Order of type paramerter decleration effects type checking #18240

Closed
Ericson2314 opened this issue Oct 22, 2014 · 1 comment
Closed

Order of type paramerter decleration effects type checking #18240

Ericson2314 opened this issue Oct 22, 2014 · 1 comment
Labels
A-typesystem Area: The type system

Comments

@Ericson2314
Copy link
Contributor

init_hack type checks, but init_hack2 doesn't, and the type error referes to a type parameter not bound in this module. I think there is some larger problem involving associated functions, as I really shouldn't need init_hack at all.

Unfortunately for the time being I cannot release my whole program because it is used in a school assignment. Reducing the program (e.g. making a new trait with just init, unused by other code) make the problem go away, so this code sample is the best I can do.

use std::io::net::ip::{Ipv4Addr, IpAddr};
use std::option::Option;
use std::sync::Arc;

use super::IpState;

pub trait RoutingTable: Send + Sync {

  // initialized with the neighbor IPs
  fn init<I>(i: I) -> Self where I: Iterator<IpAddr>;

  fn lookup(&self, IpAddr) -> Option<IpAddr>;

  fn monitor(state: Arc<IpState<Self>>) -> ();

  fn dump(&self);

}

pub fn init_hack<RT, I>(i: I) -> RT
  where RT: RoutingTable, I: Iterator<IpAddr>
{
  RoutingTable::init::<I>(i)
}

pub fn init_hack2<I, RT>(i: I) -> RT
  where RT: RoutingTable, I: Iterator<IpAddr>
{
  RoutingTable::init::<I>(i)
}

pub fn monitor_hack<RT>(s: Arc<IpState<RT>>) where RT: RoutingTable
{
  RoutingTable::monitor(s);
}
@ghost ghost added the I-wrong label Oct 22, 2014
@ghost ghost added the A-typesystem Area: The type system label Nov 2, 2014
@arielb1
Copy link
Contributor

arielb1 commented Jun 29, 2015

Trait matching got rewritten in-between - I'll close this.

@arielb1 arielb1 closed this as completed Jun 29, 2015
lnicola pushed a commit to lnicola/rust that referenced this issue Oct 22, 2024
lnicola pushed a commit to lnicola/rust that referenced this issue Oct 22, 2024
…Veykril

Clamp Position::character to line length

LSP says about Position::character

> If the character value is greater than the line length it defaults back to the line length.

but from_proto::offset() doesn't implement this.

A client might for example request code actions for a whole line by sending
Position::character=99999.  I don't think there is ever a reason (besides laziness) why the
client can't specify the line length instead but I guess we should not crash but follow protocol.

Not sure how to update Cargo.lock (lib/README.md doesn't say how).

Fixes rust-lang#18240
lnicola pushed a commit to lnicola/rust that referenced this issue Oct 22, 2024
LSP says about Position::character

> If the character value is greater than the line length it defaults back to the line length.

but from_proto::offset() doesn't implement this.

A client might for example request code actions for a whole line by sending
Position::character=99999.  I don't think there is ever a reason (besides laziness) why the
client can't specify the line length instead but I guess we should not crash but follow protocol.

Technically it should be a warning, not an error but warning is not shown by default so keep
it at error I guess.

Fixes rust-lang#18240
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
Projects
None yet
Development

No branches or pull requests

2 participants