Davy Landman

icon indicating a website link http://www.davylandman.nl icon indicating an email [email protected]

icon company @SWAT-engineering icon location Amsterdam, The Netherlands icon location Implements DSLs for a living. Parsers, typecheckers, compilers, interpreters, VS Code extensions, you name it. One of core developers of Rascal (@usethesource)

Results 265 comments of Davy Landman

Type checker: false positives for binary incompatibility when using Windows-built Rascal jars

This might be quite involved to solve, so lets park this issue until we've done a release.

Can't start constructor names with an underscore

@jurgenvinju I'm guessing this is a typechecker bug? (it's not tagged as such)

Show synopsis and/or description of alias types

I've moved this to rascal project, as rascal-lsp just forwards the documentation that the typechecker puts on it.

Deconstruct a data type crashes the typechecker

@0xJ0EY thanks for reporting this and sharing the code that triggers it @PaulKlint this is for quite an older version of the typchecker, can you check if the current version...

excessive persistence of location constituents

I've been hit by this bug as well, however I think we have to be careful. I suggest only the following operations would drop the positions: - `.parent` - `.path`...

excessive persistence of location constituents

> For `extension` we wouldn't put it back. Etc. Etc. It is going to be a long list but not a complex task. The question is always: does the new...

Syntax list type hover prints normalized separated list instead of user-level original syntax list

not sure if I would classify this as a bug @jurgenvinju, it's more of an improvement of how the type is printed?

Solving the deeper causes of #2497

My reproduction case was not invoking the test runners, I was only invoking the rascal checker via the CompileRascal class.

Assigning a overloaded constructor does not throw an exception

Also @PaulKlint the `main`-branch typechecker does not give you a static type check message for this code, should we?

Apparantly contradictory comment definition in Rascal.rsc

I've just looked at that line, and the only time we tried to change that production was to solve a windows ambiguity, but we reverted that. It has been like...