Skip to content

Fix #2334: Require at least one digit after '.' in floating point literals #2336

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

Merged
merged 31 commits into from
May 7, 2017

Conversation

odersky
Copy link
Contributor

@odersky odersky commented May 1, 2017

…erals

This seemingly simple fix opened up a few other problems with error reporting. It's based on the symbolic names PR because we need that for avoiding <error> in error messages. The commits from e8860ee are new to this PR.

@nicolasstucki nicolasstucki changed the title Fix #2334: Require at least one digit after '.' in floating point lit… Fix #2334: Require at least one digit after '.' in floating point literals May 1, 2017
@odersky odersky requested a review from felixmulder May 1, 2017 09:20
Copy link
Contributor

@felixmulder felixmulder left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great to me! :)

odersky added 26 commits May 6, 2017 22:08
1. Fix problem in fullNameSeparated
2. Revise expandedName operations
Don't encode operator symbols internally. Instead, let the
backend convert them when generating code.

# Conflicts:
#	compiler/src/dotty/tools/dotc/core/Names.scala
#	compiler/src/dotty/tools/dotc/core/StdNames.scala
#	compiler/src/dotty/tools/dotc/transform/PostTyper.scala

# Conflicts:
#	compiler/src/dotty/tools/backend/jvm/DottyBackendInterface.scala
#	compiler/src/dotty/tools/dotc/core/Names.scala
I found the problem when trying to debug what went wrong with encoded names
in backend. I added an assert that the toString of a name would not contain
symbolic operator characters. The assert triggered because an error type forced
the message (without printing to Console later).
was a patch left over from a previosu attempt to bugfix. Actually goes
wrong when reading string literals that are represented as UTF8 names.
Also: use "_$" instead of "~" as filler when taking the full name
of a term member. If the term member is symbolic (e.g. +) the
filler name would be misinterpreted as a symbolic name "~+", so would
be mangled as "$tilde$plus$ instead of "~$plus".
The return type is now ThisName instead of Name.
Avoids mutable names and the hassles associated with them.
# Conflicts:
#	compiler/src/dotty/tools/dotc/core/Names.scala
Compare unmangled name when searching for roots in Scala2 and Tasty
unpickling. Since we now load files with their unmangled name, we
don't need to go through mangled names anymore.
This was accidentally reverted from b641181.
There's no need to add mangled qualified names in the name table. Instead
we compute the mangled string directly and more efficiently.

Also, bug fixes to make semantic names work:

- When creating a fully qualified name, we need to convert the last part
  to a simple name. If the last part is not already a simple name or typename
  version of it, it should be mangled

- Mangling needs to sanitize because a legal name such as <init> might
  illegal when it gets a suffix or prefix.
The previous logic would have applied several suffixes
in reverse.
odersky added 5 commits May 6, 2017 22:08
Previously, we also interpreted the newline as a significant input,
which led to -Xprompt stopping only at every second error.
We previously got:

    an identifier expected but `=` found

even though the token that was found was a `}`! The fallacy was that
in.name is not always set to something significant. I had to refactor quite a bit
to avoid this. Anyway, I thought the code was a bit underwhelming with `null`
interpreted and an "explanation" that simply repeated what was said in the
main message.
@odersky odersky merged commit 83da57a into scala:master May 7, 2017
@allanrenucci allanrenucci deleted the fix-#2334 branch December 14, 2017 19:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants