LS: Partially revert #5214, remove error code book

[mkaput]

This change is 

[mkaput]

Reviewable status: 0 of 4 files reviewed, 3 unresolved discussions (waiting on @LucasLvy and @orizi)

---

crates/cairo-lang-language-server/src/lib.rs line 963 at r1 (raw file):

Previously, LucasLvy (Lucas @ StarkWare) wrote…

I'd consider this as an error because we are the one sending the error codes with the diagnostic.

This could be an error if all diagnostics had an error code, which is not true.

---

crates/cairo-lang-language-server/src/lib.rs line 968 at r1 (raw file):

Previously, LucasLvy (Lucas @ StarkWare) wrote…

I'd consider this as an error because we are the one sending the error codes with the diagnostic.

I don't know the exact API semantics. Are you sure this endpoint won't be triggered for diagnostics coming from other language servers, for example? If you don't know I can research this deeper.

---

crates/cairo-lang-language-server/src/lib.rs line 974 at r1 (raw file):

Previously, LucasLvy (Lucas @ StarkWare) wrote…

I'd rather match here but not very important

I wish I could do that, but unfortunately I have no idea how to express error_code!(...).as_str() as a Rust pattern. I can only do the following here, which is uglier imho:

match code {
    c if c == error_code!(E0001).as_str()
}

alternatively I might ditch error_code! entirely from here, it's actually not a big benefit 🤔

match code {
     "E0001" => ...
}

wdyt?

[0xLucqs]

Reviewable status: 0 of 4 files reviewed, 3 unresolved discussions (waiting on @mkaput and @orizi)

---

crates/cairo-lang-language-server/src/lib.rs line 963 at r1 (raw file):

Previously, mkaput (Marek Kaput) wrote…

This could be an error if all diagnostics had an error code, which is not true.

I don't know i still think that it should be logged as an error as we are probably the only who know that we want to keep 1 error code for some time

---

crates/cairo-lang-language-server/src/lib.rs line 968 at r1 (raw file):

Previously, mkaput (Marek Kaput) wrote…

I don't know the exact API semantics. Are you sure this endpoint won't be triggered for diagnostics coming from other language servers, for example? If you don't know I can research this deeper.

I guess it could, but it would still be an error imo, we only treat diagnostic that comply with our "spec". WDYT ?

---

crates/cairo-lang-language-server/src/lib.rs line 974 at r1 (raw file):

Previously, mkaput (Marek Kaput) wrote…

I wish I could do that, but unfortunately I have no idea how to express error_code!(...).as_str() as a Rust pattern. I can only do the following here, which is uglier imho:

match code {
    c if c == error_code!(E0001).as_str()
}

alternatively I might ditch error_code! entirely from here, it's actually not a big benefit 🤔

match code {
     "E0001" => ...
}

wdyt?

yes matching on the string seems good not sure what error code is bringing here.

[orizi]

Reviewed 3 of 4 files at r1, all commit messages.
Reviewable status: 3 of 4 files reviewed, 4 unresolved discussions (waiting on @LucasLvy and @mkaput)

---

crates/cairo-lang-language-server/src/lib.rs line 956 at r1 (raw file):

}

fn get_code_actions_for_diagnostic(

doc

---

crates/cairo-lang-language-server/src/lib.rs line 974 at r1 (raw file):

Previously, LucasLvy (Lucas @ StarkWare) wrote…

yes matching on the string seems good not sure what error code is bringing here.

matching does not work yet not directly on literals - it works only on nightly with a feature, and also requires a const block:
const { some_const_calc() }

[mkaput]

Reviewable status: 3 of 4 files reviewed, 4 unresolved discussions (waiting on @LucasLvy and @orizi)

---

crates/cairo-lang-language-server/src/lib.rs line 956 at r1 (raw file):

Previously, orizi wrote…

doc

Done.

---

crates/cairo-lang-language-server/src/lib.rs line 974 at r1 (raw file):

Previously, orizi wrote…

matching does not work yet not directly on literals - it works only on nightly with a feature, and also requires a const block:
const { some_const_calc() }

Done.

[mkaput]

Reviewable status: 3 of 4 files reviewed, 4 unresolved discussions (waiting on @LucasLvy and @orizi)

---

crates/cairo-lang-language-server/src/lib.rs line 963 at r1 (raw file):

Previously, LucasLvy (Lucas @ StarkWare) wrote…

I don't know i still think that it should be logged as an error as we are probably the only who know that we want to keep 1 error code for some time

Same as in the other thread: without first ensuring this is our diagnostic I don't think we should error! here.

---

crates/cairo-lang-language-server/src/lib.rs line 968 at r1 (raw file):

Previously, LucasLvy (Lucas @ StarkWare) wrote…

I guess it could, but it would still be an error imo, we only treat diagnostic that comply with our "spec". WDYT ?

As far as I understand comments, to be fully sure this is our diagnostic we would have to set the source field. And the protocol is not saying that we only get ours diagnostics as input. So I believe doing error! will be very noisy in LS logs (debug! is not printed in default mode)

[orizi]

Reviewed all commit messages.
Reviewable status: 3 of 4 files reviewed, 3 unresolved discussions (waiting on @LucasLvy)

[orizi]

Reviewed all commit messages.
Reviewable status: 3 of 4 files reviewed, 3 unresolved discussions (waiting on @LucasLvy)

[0xLucqs]

Reviewable status: 3 of 4 files reviewed, 3 unresolved discussions (waiting on @mkaput and @orizi)

---

crates/cairo-lang-language-server/src/lib.rs line 963 at r1 (raw file):

Previously, mkaput (Marek Kaput) wrote…

Same as in the other thread: without first ensuring this is our diagnostic I don't think we should error! here.

Don't you think it's an error if we receive other lsps diagnostics ?

[mkaput]

Reviewable status: 3 of 4 files reviewed, 3 unresolved discussions (waiting on @LucasLvy and @orizi)

---

crates/cairo-lang-language-server/src/lib.rs line 963 at r1 (raw file):

Previously, LucasLvy (Lucas @ StarkWare) wrote…

Don't you think it's an error if we receive other lsps diagnostics ?

I do not think it's an error. The protocol does not forbid this to happen and there is a sensible use-case for this behaviour (which we are not interested in); hence I'm ignoring this situation here.

[orizi]

Reviewable status: 3 of 4 files reviewed, 3 unresolved discussions (waiting on @LucasLvy)

[orizi]

Reviewed 1 of 1 files at r2.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @LucasLvy)

[0xLucqs]

Reviewed 3 of 4 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @mkaput)