by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jul 10 13:55
    Johann150 commented #260
  • Jul 10 13:52
    Johann150 synchronize #260
  • Jul 10 13:50
    Johann150 synchronize #260
  • Jul 10 13:43
    Johann150 synchronize #257
  • Jul 10 13:28
    Johann150 commented #257
  • Jul 10 09:52
    Johann150 commented #257
  • Jul 10 09:52
    Johann150 commented #257
  • Jul 10 09:51
    Johann150 synchronize #257
  • Jul 10 08:08
    Johann150 commented #259
  • Jul 10 08:08
    Johann150 synchronize #257
  • Jul 10 08:07
    Johann150 synchronize #260
  • Jul 10 05:02
    brendanzab commented #261
  • Jul 10 03:40
    RDambrosio016 opened #261
  • Jul 09 23:58
    brendanzab commented #257
  • Jul 09 22:52
    gembin starred brendanzab/codespan
  • Jul 09 22:17

    brendanzab on master

    feat: Make codespan_lsp use cod… Remove codespan dev dependency … Merge pull request #258 from Ma… (compare)

  • Jul 09 22:17
    brendanzab closed #258
  • Jul 09 22:12
    brendanzab commented #257
  • Jul 09 22:11
    brendanzab commented #257
  • Jul 09 17:42
    Johann150 commented #259
Brendan Zabarauskas
@brendanzab
more just trying to get the underline in the right place
Brendan Zabarauskas
@brendanzab
I did a bit more work on the underlines last night. got the single underline working - now I need to figure out how to render the messages around it! But yeah, slowly making progress…
Brendan Zabarauskas
@brendanzab
Made a draft PR here: brendanzab/codespan#241
matt rice
@ratmice
nice, so IIUC all that unicode boundary/slice handling, in label_single managed to get moved into a single iter over char_indices()?
Brendan Zabarauskas
@brendanzab
yeah!
but for some reason it's slightly offset
(see the snapshot errors)
matt rice
@ratmice
So in the AnonLabel struct from #229 I did some cursory look to see if it was possible in the case of FileId: Sized to reserve size_of in the struct but couldn't get it working without GATs, so you could avoid that extra move between Label/AnonLabel construction, I'm guessing it'd probably be possible using something like Option<NonZero*> as FileId but seems kind of a burden on users of the public API. Not actually sure that move even really matters.
the problem being you have to declare it with [u8; std::mem::size_of::<FileId: Sized>()] or some such
I guess probably i'm thinking wrong and just using MaybeUninitialized<FileId>
matt rice
@ratmice
Anyhow, getting out of my safe rust comfort zone in trying to avoid that move :)
matt rice
@ratmice
Well, let me know if this is something you believe worth investigating more.
Brendan Zabarauskas
@brendanzab
Yeah - we might need to play around with the API a bit - I guess I'm just finding it hard to visualise a solution.
Like, I was thinking maybe we could investigate other ways to build up a diagnostic. Like maybe we could have some way of building up a tree, like:
Diagnostic::error()
    FileLabel::primary(file_id, range)
    FileLabel::secondary(file_id, range)
    FileLabel::secondary(file_id, range)
FileDiagnostic::error(file_id)
    Label::primary(range)
    Label::secondary(range)
    FileLabel::secondary(file_id, range)
matt rice
@ratmice
Well, trying with MaybeUninit isn't working either because Label<FileId>, and AnonLabel<FileId> which differ only by the file_id: FileId vs file_id:MaybeUninit<FileId> still aren't guaranteed to be the same size, since they could have different field order which changes alignment I guess
Brendan Zabarauskas
@brendanzab
tbh MaybeUninit<FileId> seems rather heavy handed?
I'd rather avoid unsafe in codespan if I can help it :sweat_smile:
matt rice
@ratmice
yeah tend to agree was mostly curious if it couldn't be made to work, and if it did might be a reason to include since it's more efficient or something -- as it is what I have there is no advantage for bringing it in beyond convenience of not having to declare it yourself (which I guess is something).
Brendan Zabarauskas
@brendanzab
ahh righto
Brendan Zabarauskas
@brendanzab
added some more test cases for overlapping stuff
matt rice
@ratmice
Well, I did get a MaybeUninit variation working (essentially by making Label a newtype around AnonLabel) -- then immediately realized godbolt wasn't by default adding optimizations here, so the actual cost of the wrapper struct isn't actually so bad... Anyhow going to stop messing with that, as it didn't seem worth it really
Brendan Zabarauskas
@brendanzab
heh, can be nice to play around to see what happens though!
Brendan Zabarauskas
@brendanzab
Screen Shot 2020-05-17 at 12.30.09 pm.png
making some amount of progress
Brendan Zabarauskas
@brendanzab
Screen Shot 2020-05-17 at 4.14.52 pm.png
matt rice
@ratmice
I Imagine there probably isn't any characters which implement these edge crossing notches bridges
Brendan Zabarauskas
@brendanzab
yeah that would be so neat
need to bug the unicode consortium
matt rice
@ratmice
yeah, if u292b & c were just orthogonal/not rotated they would work too
segeljakt
@segeljakt
@brendanzab have you thought about writing a paper or something about this? many programming languages could benefit from this quality of error messages
Brendan Zabarauskas
@brendanzab
hehe, I dunno - it's more just implementation work - not sure what is significant research wise :/
segeljakt
@segeljakt
Really interesting...
I see the potential for an experiment or case study haha
Brendan Zabarauskas
@brendanzab
hehe :)
Brendan Zabarauskas
@brendanzab
Screen Shot 2020-05-17 at 11.24.24 pm.png
^ after a bunch of hacky hacks on hacks
Screen Shot 2020-05-17 at 11.26.48 pm.png
^ also
now to clean up...
segeljakt
@segeljakt
neat 👍
do you have any insights about whether error messages differ between languages?
like, imperative vs functional 🤔
Brendan Zabarauskas
@brendanzab
not sure
I just know many compilers neglect them
well, at least historically
I don't think it really matters what the dominant paradigm is
But fp langs have tended to rely on whole program type inference in the past, which can make good, localised errors more challenging to implement
But I don't think that's an FP thing - more a 'whole program type inference' thing
Currying can make good errors harder I think?