[Issue 11716] ICE on ztc\cgcv.c 2197
https://issues.dlang.org/show_bug.cgi?id=11716 Richard Cattermole changed: What|Removed |Added Status|NEW |RESOLVED CC||alphaglosi...@gmail.com Resolution|--- |WORKSFORME --- Comment #2 from Richard Cattermole --- I cannot reproduce this on Win10 with 32 and 64bit using dmd 2.077.1 If it is still an issue, reopen. --
[Issue 18146] New: A case expression of final switch allows to pass wrong enum value
https://issues.dlang.org/show_bug.cgi?id=18146
Issue ID: 18146
Summary: A case expression of final switch allows to pass wrong
enum value
Product: D
Version: D2
Hardware: x86_64
URL: http://dlang.org/phobos/
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: dmd
Assignee: nob...@puremagic.com
Reporter: kohei-c...@jcom.home.ne.jp
This issue relates enum and final switch.
The situation is shown roughly below.
An enum `Hoge' is defined in file `/foo/bar.d'.
---
enum Hoge: ubyte{Val0, Val1, Val2, Val3, Val4}
---
Then, other file `/foo/baz.d' imports `bar.d'.
template tmp(T){
class Abcd{...}
class Efgh(uint tv0, uint tv1, Hoge typ){
@safe pure nothrow @nogc{
this(){...}
this(in T[] wxyz){
static if( tv0 == tv1 ){
final switch(typ){
case Hoge.Val2:
static assert(typ == Hoge.Val2); // <- this expression throws an
assert exception!
// then, `typ' is equal to Hoge.Val1
break;
case Hoge.Val1:
...;
break;
.
.
.
}
} // End of `static if' statement
} // End of a constructor
}
} // End of class
} // End of template
--
[Issue 18147] New: Debug information limited in size
https://issues.dlang.org/show_bug.cgi?id=18147 Issue ID: 18147 Summary: Debug information limited in size Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: alphaglosi...@gmail.com Too large of debug information causes: Internal error: ddmd\backend\cgcv.c 213 This can be generated by code along the lines of (the GC struct): https://github.com/Devisualization/bindings/blob/master/source/opengl/devisualization/bindings/opengl/gl.d Removing -debug allows the code to build. For dub this is --build=plain. Disabling debug info would be fine in this case, however I am sure there is a better solution. --
[Issue 18143] in/out contracts should be implicitly 'this' const
https://issues.dlang.org/show_bug.cgi?id=18143 Iain Buclaw changed: What|Removed |Added Summary|in/out contracts should be |in/out contracts should be |implicitly const|implicitly 'this' const --
[Issue 18125] crt_constructor name conflict
https://issues.dlang.org/show_bug.cgi?id=18125 Steven Schveighoffer changed: What|Removed |Added Status|NEW |RESOLVED CC||schvei...@yahoo.com Resolution|--- |INVALID --- Comment #1 from Steven Schveighoffer --- extern(C) functions have no mangling, so you either need to name them something different, or not use extern(C). What is happening here is that you have 2 symbols in the table named initProcess, and the linker discards one. --
[Issue 18120] Allow DRT options to be set via the environment
https://issues.dlang.org/show_bug.cgi?id=18120 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #2 from Steven Schveighoffer --- so close this? --
[Issue 18124] std.regex.RegexMatch's front property is under-documented
https://issues.dlang.org/show_bug.cgi?id=18124 Steven Schveighoffer changed: What|Removed |Added Keywords||ddoc Status|RESOLVED|REOPENED CC||schvei...@yahoo.com Resolution|WONTFIX |--- Summary|Over-use of `auto` return |std.regex.RegexMatch's |type in std.regex |front property is ||under-documented Severity|enhancement |trivial --- Comment #4 from Steven Schveighoffer --- (In reply to Seb from comment #1) > Advantage of `auto`: > - we can change the API No, you can't change the API. People depend on the API being the way it is. You can change the result's innards (read: private members) whether it's auto or not, but what auto does allow is changing the NAME of the result, and not break any code. In other words, it forces you to use auto when receiving the result. But this is only for private or voldemort types. In this case, we are defining the type publicly, so using auto here just avoids writing out the type itself. Another advantage of auto is when you want to return different types based on static introspection. This allows a much DRYer mechanism than somehow generating the return type (and the result can look a lot worse than using auto). > - less visual clutter (that's subjective though) Well, we need to describe what the result actually can do. In this case, it seems the result is under-documented, so we should do *something* to fix that. Looking at the code, it seems it's returning a defined struct in the file itself, so we should just document it properly. (In reply to Neia Neutuladh from comment #2) > Just a tip: emoticons can make an otherwise professional comment seem smarmy > or condescending. If you do not intend to seem smarmy or condescending, you > may wish to avoid them. Just another tip: you may want to avoid taking unnecessary offense at innocuous things for no reason. Most people in our organization are friendly and cheerful people, including Seb. Thanks! ;) --
[Issue 18120] Document setting DRT options via the environment
https://issues.dlang.org/show_bug.cgi?id=18120 greenify changed: What|Removed |Added Component|druntime|dlang.org Summary|Allow DRT options to be set |Document setting DRT |via the environment |options via the environment --- Comment #3 from greenify --- Let's keep this open and change the purpose? Improving the documentation? For example, we could add a dedicated page about druntime's option to the spec. --
[Issue 11529] Unclear error message when rvalue is passed as `ref'
https://issues.dlang.org/show_bug.cgi?id=11529 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #3 from Nick Treleaven --- https://github.com/dlang/dmd/pull/7554 --
[Issue 15613] Parameter type mismatch error message are not very helpful
https://issues.dlang.org/show_bug.cgi?id=15613 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #2 from Nick Treleaven --- https://github.com/dlang/dmd/pull/7554 It shows the argument that failed (and matching parameter) rather than parameter index. --
[Issue 16165] Better error message for mismatched function argument types
https://issues.dlang.org/show_bug.cgi?id=16165 Nick Treleaven changed: What|Removed |Added Status|NEW |RESOLVED CC||n...@geany.org Resolution|--- |DUPLICATE --- Comment #1 from Nick Treleaven --- *** This issue has been marked as a duplicate of issue 15613 *** --
[Issue 15613] Parameter type mismatch error message are not very helpful
https://issues.dlang.org/show_bug.cgi?id=15613 Nick Treleaven changed: What|Removed |Added CC||johnnymar...@gmail.com --- Comment #3 from Nick Treleaven --- *** Issue 16165 has been marked as a duplicate of this issue. *** --
[Issue 9056] More precise error messages when function arguments are wrong
https://issues.dlang.org/show_bug.cgi?id=9056 Nick Treleaven changed: What|Removed |Added CC||n...@geany.org --- Comment #1 from Nick Treleaven --- I've mostly addressed this with a pull for Issue 15613, but I'll leave open because there's also the issue of passing the wrong number of arguments. --
[Issue 13655] clarify that a ref parameter cannot bind to an rvalue
https://issues.dlang.org/show_bug.cgi?id=13655 Nick Treleaven changed: What|Removed |Added Status|NEW |RESOLVED CC||n...@geany.org Resolution|--- |DUPLICATE --- Comment #1 from Nick Treleaven --- *** This issue has been marked as a duplicate of issue 11529 *** --
[Issue 12019] Better error message for refused ref function argument
https://issues.dlang.org/show_bug.cgi?id=12019 Nick Treleaven changed: What|Removed |Added Status|NEW |RESOLVED CC||n...@geany.org Resolution|--- |DUPLICATE --- Comment #1 from Nick Treleaven --- *** This issue has been marked as a duplicate of issue 11529 *** --
[Issue 11529] Unclear error message when rvalue is passed as `ref'
https://issues.dlang.org/show_bug.cgi?id=11529 Nick Treleaven changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #4 from Nick Treleaven --- *** Issue 12019 has been marked as a duplicate of this issue. *** --
[Issue 11529] Unclear error message when rvalue is passed as `ref'
https://issues.dlang.org/show_bug.cgi?id=11529 Nick Treleaven changed: What|Removed |Added CC||samj...@gmail.com --- Comment #5 from Nick Treleaven --- *** Issue 13655 has been marked as a duplicate of this issue. *** --
[Issue 18120] Document setting DRT options via the environment
https://issues.dlang.org/show_bug.cgi?id=18120 --- Comment #4 from Steven Schveighoffer --- Great idea! We actually I think should summarize in a nice document all the ways you can customize druntime, command line, environment, and in the binary. --
[Issue 18124] std.regex.RegexMatch's front property is under-documented
https://issues.dlang.org/show_bug.cgi?id=18124 --- Comment #5 from Neia Neutuladh --- (In reply to Seb from comment #1) > A good improvement, however, could be to improve Ddoc or documentation, s.t. > it helps the reader more what `auto` could be mean and whats capabilities > one can expect from it. std.regex.Captures has fourteen public members. You think it is better to document its public members in std.regex.match *and* std.regex.matchFirst than to just point to the types? That's an interesting perspective. (In reply to Steven Schveighoffer from comment #4) > what auto does allow is changing the NAME of the result Aliases also allow changing the name of the type even if you use concrete types. It's just that you need a deprecation cycle. So if you think there's a strong risk you *absolutely must* have another struct in std.regex named Captures in the next Phobos release, sure, keep the existing one private and use `auto` return types. If you merely think you might get a better name for it in the near future, you can change it then and add a deprecated alias for the existing name. Or, more likely, you'll be told that changing the name is bikeshedding and that you should keep it as is -- which is generally a good idea. A slightly more salient change is that you might move a type so it's more widely accessible. Perhaps a year from now we'll want to use a Captures object for a std.string.find function. A public import if the name is kept the same, or an alias if it is not, functions just as well as using an auto return type. The only change that it possibly lets you do is change between several existing types instead of committing to the same type for each. In this case, the implementation for std.regex.matchFirst is a manually inlined version of return matchMany(args).front; That makes it unlikely that the types will become incompatible. > Just another tip: you may want to avoid taking unnecessary offense at > innocuous things for no reason. Most people in our organization are friendly > and cheerful people, including Seb. Thanks! ;) In point of fact, what I experienced was _anger_, not offense. Detached professionalism doesn't give anger a target. By reiterating a behavior I just complained about in response to me complaining about it, it looks like you are trying to deliberately antagonize me. This is a concept that most of my cohort had grasped by second grade. I believe you've been in the D community as long as me, which means you should be an adult, or near enough. Do you have some sort of social disability that makes it difficult for you to learn things like this? If so, I'll try to take that into account in our future interactions. --
[Issue 18124] std.regex.RegexMatch's front property is under-documented
https://issues.dlang.org/show_bug.cgi?id=18124 --- Comment #6 from Steven Schveighoffer --- (In reply to Neia Neutuladh from comment #5) > If you merely think > you might get a better name for it in the near future, you can change it > then and add a deprecated alias for the existing name. I think we can keep things as is, but just document that RegexMatch.front returns a Captures struct. After all, Captures is already documented. > A slightly more salient change is that you might move a type so it's more > widely accessible. Perhaps a year from now we'll want to use a Captures > object for a std.string.find function. A public import if the name is kept > the same, or an alias if it is not, functions just as well as using an auto > return type. I don't think we need to move types around yet. When I look at std.regex docs, Captures has a lot of documentation, we just don't have the link between RegexMatch.front and the struct it returns (a downside of auto here). We just need to make that link. > > Just another tip: you may want to avoid taking unnecessary offense at > > innocuous things for no reason. Most people in our organization are friendly > > and cheerful people, including Seb. Thanks! ;) > > In point of fact, what I experienced was _anger_, not offense. Detached > professionalism doesn't give anger a target. > > By reiterating a behavior I just complained about in response to me > complaining about it, it looks like you are trying to deliberately > antagonize me. This is a concept that most of my cohort had grasped by > second grade. I believe you've been in the D community as long as me, which > means you should be an adult, or near enough. Wow! It's a smiley, it literally is just a way to put a happy, friendly face on a comment. You were angry because someone typed a smiley and you grossly misinterpreted it? Have you used the Internet before? > Do you have some sort of social disability that makes it difficult for you > to learn things like this? If so, I'll try to take that into account in our > future interactions. Yes, I learned to get over trivialities that are obviously not meant for offense before they made me angry. Pretty much around the same time (2nd grade you say?) you were learning... whatever it is you are calling tantruming here. By all means, we can stop this OT conversation, but let's get some good work done and move on. --
[Issue 18124] std.regex.RegexMatch's front property is under-documented
https://issues.dlang.org/show_bug.cgi?id=18124 --- Comment #7 from | --- (In reply to Steven Schveighoffer from comment #6) > Yes, I learned to get over trivialities that are obviously not meant for > offense before they made me angry. In other words, the other boys were jerks at you, and you learned to ignore it, so you're a jerk in response. > By all means, we can stop this OT conversation, but let's get some good work > done and move on. If you wanted to stop having the OT conversation, you could have just...not replied to that part. --
[Issue 17746] Improve BigInt memory usage
https://issues.dlang.org/show_bug.cgi?id=17746 Jack Stouffer changed: What|Removed |Added CC||j...@jackstouffer.com Hardware|x86_64 |All OS|Linux |All --
[Issue 18148] Integral Promotion Fix For 16997 Should Not Issue Deprecation, Not A Warning
https://issues.dlang.org/show_bug.cgi?id=18148 Jack Stouffer changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=16997 --
[Issue 18148] New: Integral Promotion Fix For 16997 Should Not Issue Deprecation, Not A Warning
https://issues.dlang.org/show_bug.cgi?id=18148 Issue ID: 18148 Summary: Integral Promotion Fix For 16997 Should Not Issue Deprecation, Not A Warning Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: critical Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: j...@jackstouffer.com We've had this discussion before on the forums but I think it needs to be restated: Using a warning as part of the deprecation cycle is a poor choice because the majority of build setups (including DUB) have "warnings as errors" set by default (this is the sensible thing to do). This means that you're breaking people's code on step one of the cycle. Instead, this should issue a deprecation message, then a warning, then an error. --
[Issue 16997] Integral promotion rules not being followed for unary + - ~ expressions
https://issues.dlang.org/show_bug.cgi?id=16997 Jack Stouffer changed: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=18148 --
[Issue 13761] Clang Static Analysis results for dmd
https://issues.dlang.org/show_bug.cgi?id=13761 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dmd https://github.com/dlang/dmd/commit/e7f6ceca1324d15d3df5999569c62138c4b594c8 Partial fix for Issue 13761 - Fix code which triggers warnings https://github.com/dlang/dmd/commit/62778ea7f09c28ed9cda40ee980bf54dab0113b1 Merge pull request #7557 from ibuclaw/partial13761 Partial fix for Issue 13761 - Fix code which triggers warnings merged-on-behalf-of: Mike Franklin --
[Issue 12552] Review DMD's Static Analysis as Produced by Intel's C++ Compiler
https://issues.dlang.org/show_bug.cgi?id=12552 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED CC||ibuc...@gdcproject.org Resolution|--- |WONTFIX --- Comment #1 from Iain Buclaw --- As the front-end has been converted to D. Any sort of static analysis reports are effectively useless for us now. --
[Issue 13761] Clang Static Analysis results for dmd
https://issues.dlang.org/show_bug.cgi?id=13761 Iain Buclaw changed: What|Removed |Added Status|NEW |RESOLVED CC||ibuc...@gdcproject.org Resolution|--- |WONTFIX --- Comment #4 from Iain Buclaw --- As the front-end has been converted to D. Any sort of static analysis reports are effectively useless for us now. --
