I'm glad throw is now an expression (page 2)

On 18/05/2022 8:50 AM, kdevel wrote: > On Tuesday, 17 May 2022 at 20:06:35 UTC, kdevel wrote: > [...] >> Is this reproducible? > > Issue 23120 - dmd illegal instruction throw expression https://issues.dlang.org/show_bug.cgi?id=23120

On Tuesday, 17 May 2022 at 21:05:08 UTC, deadalnix wrote:

On Tuesday, 17 May 2022 at 14:41:24 UTC, Basile B. wrote:

Proper syntax coloring is based on the lexems and shall not break. I'd be curious to know which are the text editors that cant colorize throw anymore.

Proper syntax coloring does way more than this and has been for the past 20 years. Highlight invalid constructs, display types, expression and alike differently, etc...

Almost any modern text editor will use much more than a lexer. Most of them don't support D, for obvious reasons. I use sublime text, which has decent support for D.

Yes I see that ST does more. It has several other issues. 100% of them are caused by the fact that they need to keep up to date with the grammar. That's a pity, an old unproper syntax coloring based on the tokens would work just fine.

May 17, 2022

Re: I'm glad throw is now an expression

Posted by Steven Schveighoffer
in reply to deadalnix

Permalink

Steven Schveighoffer

Posted in reply to deadalnix

Permalink

On 5/17/22 8:47 PM, deadalnix wrote:

On Tuesday, 17 May 2022 at 22:03:38 UTC, Basile B. wrote:

No it would not.

You just can't provide the same level of support with lexing you can with parsing, this is why we have parsers to begin with.

This attitude is why tooling is so poor for D to begin with.

libdparse supports the new syntax in question. I'm not sure what more D can do. D updated the parser, which is an official open-source library that implements the parser. It can't make other projects give up their NIH parsers.

If someone implemented a D parser in brainfuck, would D have to make sure it updated that parser before progressing, just because it's a parser?

-Steve

On 5/17/2022 1:57 PM, max haughton wrote: > This is an assertion in the backend (Walter you need to fix these they are blocking work on noreturn). The backend assert is doing its job. Somewhere in the compiler the + should be turned into a ,

On Wednesday, 18 May 2022 at 07:30:15 UTC, Walter Bright wrote: > On 5/17/2022 1:57 PM, max haughton wrote: >> This is an assertion in the backend (Walter you need to fix these they are blocking work on noreturn). > > The backend assert is doing its job. Somewhere in the compiler the + should be turned into a , These is plural unfortunately. There's one particular cod1 ptregs assertion that comes up *a lot* but unlike this assertion it gives no context other than something broken

On 5/18/2022 12:35 AM, max haughton wrote: > On Wednesday, 18 May 2022 at 07:30:15 UTC, Walter Bright wrote: >> On 5/17/2022 1:57 PM, max haughton wrote: >>> This is an assertion in the backend (Walter you need to fix these they are blocking work on noreturn). >> >> The backend assert is doing its job. Somewhere in the compiler the + should be turned into a , > > These is plural unfortunately. There's one particular cod1 ptregs assertion that comes up *a lot* but unlike this assertion it gives no context other than something broken More thinking about this suggests that int+noreturn should be typed as noreturn.

Forums