Skip to content

[Diag] Create frontend flags for localization and write tests #32568

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 2 commits into from
Jun 30, 2020

Conversation

HassanElDesouky
Copy link
Contributor

In the last PR #32483, I introduced localization support for diagnostics via file-per-language store in YAML format.

In this PR I'm introducing the following:

  • Retrieve the diagnostic messages path from the compiler toolchain.
  • Create a -locale compiler frontend flag for choosing the language.
  • Create a -localization-path compiler frontend flag to provide a path for the YAML files (to use in testing).
  • Write tests.

The tests handle these cases:

  • If the language locale code isn't supported. In this case, we won't crash the compiler but instead show an error message of the supported locale codes.
  • If the path provided to -localization-path is incorrect i.e. the directory is missing the YAML files. We won't crash the compiler but instead, we should fall back to the default messages from the current .def files.
  • If the current <lang>.yaml doesn't have a translation for a particular diagnostic message it should fall back to the English message found in .def files.
  • Finally, if the message is translated and available it should, of course, show the translated message.

In the future PRs, I should handle lint tools for YAML files and prune tools to prune the diagnostics that gets removed from .def files.

cc @xedin

@HassanElDesouky
Copy link
Contributor Author

HassanElDesouky commented Jun 26, 2020

@LucianoPAlmeida in #32483 you were suggesting using an assertion rather than an if statement here:
https://github.com/apple/swift/blob/master/include/swift/AST/DiagnosticEngine.h#L743
Can you please, explain more why to do that?

@xedin
Copy link
Contributor

xedin commented Jun 26, 2020

@HassanElDesouky I can just on that an tell you why - since it's expected that locale and path are always there when setLocalization is called it's usually good to validate that assertion with assert to make sure that it's always true :)

Copy link
Contributor

@xedin xedin left a comment

Choose a reason for hiding this comment

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

Overall looks great! Let's get comments I have left inline addressed and this would be ready to merge.

@LucianoPAlmeida
Copy link
Contributor

@HassanElDesouky I can just on that an tell you why - since it's expected that locale and path are always there when setLocalization is called it's usually good to validate that assertion with assert to make sure that it's always true :)

Exactly how @xedin said :)
It is a good way to make it easier for the caller to spot the error if it passed the wrong value by mistake. In this case, just silent not setting the locale based on an implementation detail condition not known by the caller, could lead to a "why is not setting?" and some time after that trying to figure out.

Copy link
Contributor

@xedin xedin left a comment

Choose a reason for hiding this comment

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

Everything is coming along now! I have left just a couple of comments inline and once addressed we should be ready!

Copy link
Contributor

@xedin xedin left a comment

Choose a reason for hiding this comment

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

LGTM!

@xedin
Copy link
Contributor

xedin commented Jun 30, 2020

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - 935ac0c8e7a8f48a7eae241ee3acf5898961fdd7

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 935ac0c8e7a8f48a7eae241ee3acf5898961fdd7

@xedin xedin merged commit 621b3b4 into swiftlang:master Jun 30, 2020
@davezarzycki
Copy link
Contributor

I'm going to need to revert this. The driver is double faulting on my Linux box (Fedora 32 / x86-64). It crashes due to heap corruption, then hangs trying to introspect and print the stack. There also appears to be an unrelated(?) uninitialized memory error that valgrind detects (as opposed to malloc's own self diagnostics):

 $ env SDKROOT=/ valgrind '/home/dave/b/q/t/bin/swift' -module-cache-path '/home/dave/b/q/t/swift-test-results/x86_64-unknown-linux-gnu/clang-module-cache' -swift-version 4  -Xfrontend -ignore-module-source-info -locale NOT_A_LOCALE
==2090498== Memcheck, a memory error detector
==2090498== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2090498== Using Valgrind-3.16.0 and LibVEX; rerun with -h for copyright info
==2090498== Command: /home/dave/b/q/t/bin/swift -module-cache-path /home/dave/b/q/t/swift-test-results/x86_64-unknown-linux-gnu/clang-module-cache -swift-version 4 -Xfrontend -ignore-module-source-info -locale NOT_A_LOCALE
==2090498==
==2090498== Syscall param execve(envp[i]) points to uninitialised byte(s)
==2090498==    at 0x983B45B: execve (in /usr/lib64/libc-2.31.so)
==2090498==    by 0x256386A: swift::driver::Compilation::performSingleCommand(swift::driver::Job const*) (in /home/dave/b/q/t/bin/swift-frontend)
==2090498==    by 0x256411A: swift::driver::Compilation::performJobs(std::__1::unique_ptr<swift::sys::TaskQueue, std::__1::default_delete<swift::sys::TaskQueue> >&&) (in /home/dave/b/q/t/bin/swift-frontend)
==2090498==    by 0x2550584: run_driver(llvm::StringRef, llvm::ArrayRef<char const*>) (in /home/dave/b/q/t/bin/swift-frontend)
==2090498==    by 0x254F547: main (in /home/dave/b/q/t/bin/swift-frontend)
==2090498==  Address 0x72ea02f is in the brk data segment 0x72ea000-0x72ea02f
==2090498==
malloc(): invalid next size (unsorted)
Stack dump:
0.      Program arguments: /home/dave/b/q/t/bin/lldb --repl=-disable-objc-interop -sdk / -color-diagnostics -module-cache-path /home/dave/b/q/t/swift-test-results/x86_64-unknown-linux-gnu/clang-module-cache -swift-version 4 -locale NOT_A_LOCALE -ignore-module-source-info
^C
$

That being said, if I bypass the driver, it works.

davezarzycki added a commit to davezarzycki/swift that referenced this pull request Jun 30, 2020
…swiftlang#32568)"

This reverts commit 621b3b4.

The driver is double faulting on my Linux box (Fedora 32 / x86-64). It
crashes due to heap corruption, then hangs trying to introspect and
print the stack. There also appears to be an unrelated(?) uninitialized
memory error that valgrind detects (as opposed to malloc's own self
diagnostics).

Diags.diagnose(SourceLoc(), diag::error_invalid_locale_code,
availableLocaleCodes);
return true;
Copy link
Member

Choose a reason for hiding this comment

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

This should not return after erroring. It should just ignore the bogus -locale

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks!

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.

7 participants