- Sponsor
-
Notifications
You must be signed in to change notification settings - Fork 267
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
Removed Phobos 1 from LDC tree. #1
Merged
Merged
+0
−51,732
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If anyone wanted to ever resurrect LDC1/Phobos (lphobos/README.txt had an »unmaintained« notice for more than three years now), this should be done in an external repository.
dnadlinger
added a commit
that referenced
this pull request
Aug 8, 2011
Removed Phobos 1 from LDC tree.
redstar
pushed a commit
that referenced
this pull request
Sep 27, 2014
regression test for Issue 10701
redstar
pushed a commit
that referenced
this pull request
Sep 27, 2014
missing executeArgs for benchmarks
Closed
timotheecour
pushed a commit
to timotheecour/ldc
that referenced
this pull request
Dec 13, 2017
TemplateSpecializationType might be sugar for InjectedClassNameType too.
timotheecour
pushed a commit
to timotheecour/ldc
that referenced
this pull request
Dec 13, 2017
A major source of headaches and probably the source ldc-developers#1 of mapping failures for sophisticated C++ libraries has been the restrictions of D template instantiation scope. Those restrictions are totally necessary and work great in D, and Clang adding "sugar" to its types made it possible to comply with them... most of the time. One particular wall was hit while trying to map the MSVC standard library. For type_traits's conjunction<_Is_character<char>, _Is_character<char>>, the base class in Clang's AST is: TemplateSpecializationType 0xdfaed30 '_Conjunction<struct std::_Is_character<char>, struct std::_Is_character<char> >' sugar _Conjunction | -TemplateArgument type 'struct std::_Is_character<char>':'struct std::_Is_character<char>' | SubstTemplateTypeParmType 0xdda9f20 'struct std::_Is_character<char>' sugar | -TemplateTypeParmType 0xa7ce0f0 '_Traits' dependent contains_unexpanded_pack depth 0 index 0 pack | `-TemplateTypeParm 0xa7ce0c0 '_Traits' `-RecordType 0xa9079d0 'struct std::_Is_character<char>' `-ClassTemplateSpecialization 0xa907930 '_Is_character' | -TemplateArgument type 'struct std::_Is_character<char>' : 'struct std::_Is_character<char>' | SubstTemplateTypeParmType 0xdda9f20 'struct std::_Is_character<char>' sugar (...same as above....) `-RecordType 0xdfaed10 'struct std::_Conjunction<struct std::_Is_character<char>, struct std::_Is_character<char> >' `-ClassTemplateSpecialization 0xdfaec78 '_Conjunction' This is one of those rare cases where Clang has lost pack information and no simple/good heuristic to guess when two or more arguments come from the same pack appears to be possible. Hence either Clang needs to be modified to preserve pack info, or a complicated check/heuristic is needed, or we've got to stop trying to stick to DMD's way. The third option was chosen because there's actually no good reason to comply with those restrictions. Reflection doesn't get improved, and while instantiation from C++ modules, every referenced symbol is from C++ modules. So from now on: - Every type gets desugared before being mapped in non-dependent contexts. - C++ modules now have access to the "C++ global namespace" during name lookups, through a special type of global import. This allows to discard the C++ symbol collector and substitution complicated hack when mapping template arguments deduced by Sema.
This was referenced Oct 28, 2018
kinke
added a commit
that referenced
this pull request
Sep 1, 2023
I guess the recent removal of module constructors in druntime has brought these to light, for a little LDC ASan smoke test, which newly complains with D v2.105, e.g.: > Direct leak of 78624 byte(s) in 126 object(s) allocated from: > #0 0x55606978c40d in malloc /local/mnt/workspace/tmp/final/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3 > #1 0x5560698050b1 in _D2rt5minfo11ModuleGroup9sortCtorsMFNbAyaZv
kinke
added a commit
to kinke/ldc
that referenced
this pull request
Sep 1, 2023
I guess the recent removal of module constructors in druntime has brought these to light, for a little LDC ASan smoke test, which newly complains with D v2.105, e.g.: > Direct leak of 78624 byte(s) in 126 object(s) allocated from: > #0 0x55606978c40d in malloc /local/mnt/workspace/tmp/final/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:145:3 > ldc-developers#1 0x5560698050b1 in _D2rt5minfo11ModuleGroup9sortCtorsMFNbAyaZv
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If anyone wanted to ever resurrect LDC1/Phobos (lphobos/README.txt had an »unmaintained« notice for more than three years now), this should be done in an external repository.