DMD Patch to fix build on OpenIndiana (and Solaris)#2
Merged
1 commit merged intodlang:masterfrom Feb 5, 2011
Merged
Conversation
Member
|
thanks! |
braddr
pushed a commit
to braddr/dmd
that referenced
this pull request
Oct 22, 2012
Added SMTP protocol - thanks jcao219
ghost
mentioned this pull request
MartinNowak
pushed a commit
that referenced
this pull request
Nov 30, 2013
…ple not type Foo
Even if a variable has no valid context, it would be either:
1. a part of compile time evaluated expression, which is used as unreal context.
enum x = Type.fieldvar.sizeof;
// It's legitimate expression so fieldvar is not evaluated
// in runtime.
2. or an invalid field access without valid 'this', in runtime evaluated expression.
int y = Type.fieldvar;
// It's invalid expression so fieldvar access has no valid 'this'.
For the case #2, it will be an error by `checkRightThis` later. Therefore `getRightThis` should not make it an error.
ghost
mentioned this pull request
andralex
added a commit
that referenced
this pull request
Jul 14, 2016
Trivial: switch to Ddoc module comment #2
skl131313
pushed a commit
to skl131313/dmd
that referenced
this pull request
Jan 24, 2017
Fix dlang#2 - incorrect construct of typeinfo for tuple
MartinNowak
referenced
this pull request
in MartinNowak/dmd
Feb 15, 2017
Revert "Merge pull request #2 from MartinNowak/test-pr-2"
marler8997
added a commit
to marler8997/dmd
that referenced
this pull request
Dec 25, 2018
jmdavis
added a commit
to jmdavis/dmd
that referenced
this pull request
Feb 23, 2024
…inux. You can see the correct declaration for ifaddrs on Linux here: See: https://www.man7.org/linux/man-pages/man3/getifaddrs.3.html What the fields are supposed to be named is ifa_broadaddr and ifa_dstaddr. However, because Linux defines them using a union, it gives them different names within the union - ifu_broadaddr and ifu_dstaddr - and then #defines the proper names to access the union names. What druntime did was use the union names - and then incorrectly name ifu_dtsaddr as if_dstaddr. So, it was doubly wrong for that field. The two approaches that we could take here would be to either 1. Turn the union into a type so that we could have an ifa_ifu field to allow accessing the ifu_* names that way - as is technically possible in C - and then add wrapper functions with the ifa_* names (since we couldn't use an alias to access members of the union member variable). 2. Just rename the fields to ifa_* and ignore the fact that you can technically access the ifu_* fields via the union name in C. The simpler approach is dlang#2, so that's what this commit does. I'm pretty sure that the ability to access the ifu_* fields via the union name is just an implementation detail - particularly since other platforms just declare the ifa_* names without using a union at all. Either way, deprecated aliases are provided so that existing code doesn't break.
jmdavis
added a commit
to jmdavis/dmd
that referenced
this pull request
Feb 23, 2024
…inux. You can see the correct declaration for ifaddrs on Linux here: https://www.man7.org/linux/man-pages/man3/getifaddrs.3.html What the fields are supposed to be named is ifa_broadaddr and ifa_dstaddr. However, because Linux defines them using a union, it gives them different names within the union - ifu_broadaddr and ifu_dstaddr - and then #defines the proper names to access the union names. What druntime did was use the union names - and then incorrectly name ifu_dtsaddr as if_dstaddr. So, it was doubly wrong for that field. The two approaches that we could take here would be to either 1. Turn the union into a type so that we could have an ifa_ifu field to allow accessing the ifu_* names that way - as is technically possible in C - and then add wrapper functions with the ifa_* names (since we couldn't use an alias to access members of the union member variable). 2. Just rename the fields to ifa_* and ignore the fact that you can technically access the ifu_* fields via the union name in C. The simpler approach is dlang#2, so that's what this commit does. I'm pretty sure that the ability to access the ifu_* fields via the union name is just an implementation detail - particularly since other platforms just declare the ifa_* names without using a union at all. Either way, deprecated aliases are provided so that existing code doesn't break.
RazvanN7
pushed a commit
that referenced
this pull request
Feb 26, 2024
…inux. (#16233) You can see the correct declaration for ifaddrs on Linux here: https://www.man7.org/linux/man-pages/man3/getifaddrs.3.html What the fields are supposed to be named is ifa_broadaddr and ifa_dstaddr. However, because Linux defines them using a union, it gives them different names within the union - ifu_broadaddr and ifu_dstaddr - and then #defines the proper names to access the union names. What druntime did was use the union names - and then incorrectly name ifu_dtsaddr as if_dstaddr. So, it was doubly wrong for that field. The two approaches that we could take here would be to either 1. Turn the union into a type so that we could have an ifa_ifu field to allow accessing the ifu_* names that way - as is technically possible in C - and then add wrapper functions with the ifa_* names (since we couldn't use an alias to access members of the union member variable). 2. Just rename the fields to ifa_* and ignore the fact that you can technically access the ifu_* fields via the union name in C. The simpler approach is #2, so that's what this commit does. I'm pretty sure that the ability to access the ifu_* fields via the union name is just an implementation detail - particularly since other platforms just declare the ifa_* names without using a union at all. Either way, deprecated aliases are provided so that existing code doesn't break.
deadalnix
pushed a commit
to deadalnix/dmd
that referenced
this pull request
Sep 2, 2024
Make sure the main theread is busy when registering the GC
gorsing
referenced
this pull request
in gorsing/dmd
Jul 14, 2025
# This is the 1st commit message: refactoring # This is the commit message #2: refactoring # This is the commit message #3: refactoring # This is the commit message #4: refactoring # This is the commit message #5: refactoring # This is the commit message #6: refactoring # This is the commit message #7: refactoring # This is the commit message #8: refactor/irstate-attrs refactoring add pragma(inline, true) change pragma(inline, true) -> pragma(inline, false) introduce root.Array.only and test it out in expressionsem (dlang#21520) [attrib.d] remove unused semantic import [dstruct.d] remove unused import [aggregate.d] move `searchCtor` to `expressionsem.d` remove some now unused semantic symbols from the import list. [cond.d] remove unused `typesem` import (dlang#21538) [expression.d] restrict `typesem` import fix dlang#19587 No debug line info for simple code blocks (dlang#21544) set location info on return statement, not only on return expression [dsymbol.d] remove dependance on glue layer (dlang#21532) move `loadModuleFromLibrary` to `dsymbolsem.d` (dlang#21535) remove `dmodule.d` dependance of a few more `dsymbolsem.d` symbols. [func.d] remove dependance on glue layer (dlang#21534) [aggregate.d] move `checkOverlappedFields` to `dsymbolsem.d` (dlang#21542) and make private Templatize `_adEq2` (dlang#21513) * Mark array literals as `on-stack` to bypass `@nogc` analysis * Update `fail_compilation` test output After updating the memcmp-ability criteria, now dynamic array can also be compared using `memcmp` if their element type is comparable bit by bit. refactor: use new array constructor throughout expressionsem refactoring refactoring refactoring refactoring refactoring refactoring refactoring refactoring refactoring
thewilsonator
pushed a commit
that referenced
this pull request
Sep 11, 2025
Limit the number of platforms that this is done on. A inspection of some libc implementations of fork has identified the main culprits, don't need to apply this to any others. MacOS testsuite also regressed as a result on calling this code, it's not clear why, but the backtrace is: ``` * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0) * frame #0: 0x00007ff81abe6ee3 libsystem_platform.dylib`_os_unfair_lock_recursive_abort + 23 frame #1: 0x00007ff81abe12da libsystem_platform.dylib`_os_unfair_lock_lock_slow + 247 frame #2: 0x00007ff81abccd44 libsystem_pthread.dylib`_pthread_atfork_prepare_handlers + 48 frame #3: 0x00007ff825dc2705 libSystem.B.dylib`libSystem_atfork_prepare + 25 frame #4: 0x00007ff81aac17e1 libsystem_c.dylib`fork + 24 frame #5: 0x0000000101f730ee test_runner`core.internal.backtrace.dwarf.resolveAddressesWithAtos(Location[]) + 210 ```
This pull request was closed.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Yeah, it's not supported in D2 yet (but looking into that), only additions needed are 2 alloca.h includes.
Regards