A warning message should be considered, too.
Thu, Dec 3
Wed, Dec 2
I don't think that moving a temporary data structure from declaration processing into a more permanent object like Scope to accomplish scoping is the right way to fix this problem, unfortunately.
Wed, Nov 18
Tue, Nov 17
Is this particular concern now resolved by the change to std::list<>?
Mon, Nov 16
Fri, Nov 13
Thu, Nov 12
Clean up English usage & conform with Markdown usage now in use in other documentation files.
Fix bug noticed by Jean.
Wed, Nov 11
Please see D91210 for a replacement implementation in terms of std::list<>.
Remove needless <deque>
I think that the root cause of the build failure is the circular dependency: FortranSemantics <-> FortranEvaluate <-> FortranSemantics. Adding inline to IsModule and IsSubmodule fixes this particular build issue, but not the circular dependency.
Tue, Nov 10
The point is to use std::forward_list::splice_after() for efficient combination of messages.
Unfortunately it also means that we have to search for the new last element since we cannot assume that iterators of the consumed list became iterators for the resulting list. This probably eats up any potations savings. There isn't a a guarantee that splice_after is O(1) anyway.
Nov 3 2020
Nov 2 2020
Oct 30 2020
Oct 23 2020
Looks great to me; thanks!
Oct 21 2020
There may be path separators with UNIX assumptions in the runtime I/O support library, too.
Oct 19 2020
Why is this a fatal error, rather than a warning? If the TARGET= argument lacks both POINTER and TARGET attributes, the result will always be false, and we can warn about that.
Oct 16 2020
Please add a comment that lays out our reasoning for the prohibition against combining PARAMETER and POINTER, since the standards do not explicitly preclude it. (The PARAMETER attribute requires a entity-decl to have an initialization that is a constant-expr, and the only form of initialization that allows a constant-expr is the one that's not a "=>" pointer initialization.) See C811, C807, & 8.5.13.
Oct 15 2020
LGTM and thanks!
Oct 14 2020
Please see https://reviews.llvm.org/D89435 for a proposed alternative patch.
I think a better fix would be to generalize ToUInt64 as a template elsewhere. I'll prepare a patch and add you as the reviewer.
Oct 8 2020
There's a lot of work here and it's quite well done; thank you.